Summary: | =dev-libs/ucommon-5.2.2-r3[gnutls,-ssl] fails to compile with net-libs/gnutls[nettle] | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Vicente Olivert Riera (RETIRED) <vincent> |
Component: | Current packages | Assignee: | Andreis Vinogradovs ( slepnoga ) <andreis.vinogradovs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | maksbotan, proxy-maint |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 438284 | ||
Attachments: |
build log
proposed changes to the ebuild |
Description
Vicente Olivert Riera (RETIRED)
2012-10-14 17:27:25 UTC
Seems to be more fallout of gnutls[nettle]. Unfortunately, it not clear what would be a correct solution here, as it doesn't seem as if this locking is simply redundant with nettle...or is it ? Yeah okay, so there are two problems to the ebuild: 1) to get gnutls you must pass --with-sslstack=gnu and the ebuild is not doing that. 2) you must not pass --with-pkg-config. Don't worry the .pc files are still created. I have yet to understand by this leads to badness, but that can be the next bug. 1 sec, and i'll produce a patch to the current ebuild ... Created attachment 326688 [details]
proposed changes to the ebuild
(In reply to comment #3) > Created attachment 326688 [details] > proposed changes to the ebuild our ideas are the same ;) https://code.google.com/p/slepnoga/source/detail?r=852d9a354bf2ebf42305d732e2105362eb51c0ca (In reply to comment #3) > Created attachment 326688 [details] > proposed changes to the ebuild I have applied your patch to the ebuild and then I have tested the package. It works fine here, on amd64. + 21 Oct 2012; Sergey Popov <pinkbyte@gentoo.org> ucommon-5.2.2-r3.ebuild: + Fix for bug #438354, thanks to Anthony Basile That's the WRONG fix. ssl and gnutls USE flags always work _together_ not as part of REQUIRED_USE! (In reply to comment #7) > That's the WRONG fix. > > ssl and gnutls USE flags always work _together_ not as part of REQUIRED_USE! What do you mean? ssl in this context means OpenSSL support and gnutls - support for GnuTLS. Both stacks can not be used in ucommon, if i do not miss something... That's true for almost every other package that has both USEs. Check wget for an example. And please tell your mentor to explain to you how that works, since it seems like he forgot something. (In reply to comment #9) > That's true for almost every other package that has both USEs. > > Check wget for an example. > > And please tell your mentor to explain to you how that works, since it seems > like he forgot something. Thanks for fix, Diego, it seems that i have wrongly understood ssl USE-flag description. I have done such proper fix for echoping package recently, relying on wget package. But i also have question about your fix - what happens if 'gnutls' USE-flag will be enabled without 'ssl' one? For now, package will be compiled without any SSL support. I think that this is a little wrong, maybe we should add REQUIRED_USE="gnutls? ( ssl )" ? the failure still happens for me. Same way. USE='-cxx -doc gnutls -socks ssl -static-libs' failed for dev-libs/ucommon USE='cxx -doc gnutls -socks ssl -static-libs' failed for dev-libs/ucommon USE='-cxx doc gnutls -socks ssl -static-libs' failed for dev-libs/ucommon USE='cxx doc gnutls -socks ssl -static-libs' failed for dev-libs/ucommon USE='-cxx -doc gnutls socks ssl -static-libs' failed for dev-libs/ucommon USE='cxx -doc gnutls socks ssl -static-libs' failed for dev-libs/ucommon USE='-cxx doc gnutls socks ssl -static-libs' failed for dev-libs/ucommon USE='cxx doc gnutls socks ssl -static-libs' failed for dev-libs/ucommon USE='-cxx -doc gnutls -socks ssl static-libs' failed for dev-libs/ucommon USE='cxx -doc gnutls -socks ssl static-libs' failed for dev-libs/ucommon USE='-cxx doc gnutls -socks ssl static-libs' failed for dev-libs/ucommon USE='cxx doc gnutls -socks ssl static-libs' failed for dev-libs/ucommon USE='-cxx -doc gnutls socks ssl static-libs' failed for dev-libs/ucommon USE='cxx -doc gnutls socks ssl static-libs' failed for dev-libs/ucommon USE='-cxx doc gnutls socks ssl static-libs' failed for dev-libs/ucommon USE='cxx doc gnutls socks ssl static-libs' failed for dev-libs/ucommon (In reply to comment #11) > the failure still happens for me. Same way. No, not the same way, i think, but this bug is definitely not fixed. It seems that ucommon needs exactly net-libs/gnutls[-nettle], will make additional checks soon... (In reply to comment #12) > (In reply to comment #11) > > the failure still happens for me. Same way. > > No, not the same way, i think, but this bug is definitely not fixed. It > seems that ucommon needs exactly net-libs/gnutls[-nettle], will make > additional checks soon... Wel, my point in comment 1 was it looks a bit like like all the threading locks are done for gcrypt sake only, so it just *might* be redundant with gnutls[nettle]. But likely it's a question only upstream can answer. (In reply to comment #13) > Wel, my point in comment 1 was it looks a bit like like all the threading > locks are done for gcrypt sake only, so it just *might* be redundant with > gnutls[nettle]. But likely it's a question only upstream can answer. It seems, that build system relies on GnuTLS flags, obtained through pkgconfig. When gnutls compiled with USE="nettle" it does not depend on libgcrypt, so, '-lgcrypt' is not added to linker when compiling ucommon and compile failed. libgcrypt headers included in ucommon directly(if it builds with USE="gnutls"), so it seems that we need to override libs, that is sended to linker. I have tried quick-and-dirty way - 'append-libs' from flag-o-matic eclass, but with no luck :-( + 02 Nov 2012; Sergey Popov <pinkbyte@gentoo.org> ucommon-5.2.2-r3.ebuild: + Add workaround for USE="gnutls" dependencies by locking it on gnutls[-nettle] This is temp workaround, need to find a better solution... @comment 14: that's about the opposite what I was trying to say. For what I've learned from other gnutls[nettle], before gnutls started to use nettle, there was no choice for gnutls but gcrypt, which, while used internally, needed to be initialized explicitly. The initialization wasn't quite (maybe even at all) thread-safe. AFAIK, nettle doesn't have such library level initialization. But only upstream can tell whether or not gcrypt is used for anything but gnutls+gcrypt. Ок, I found the cause of this bug. It's 3 level dependencu bug, i.e gnutls[nettle] not used/install libgcrypt; but gnutls[-nettle] does it. It's build system bug ( since ancient times, when there was no support nettle in gnutls) . grep -R gcrypt ./* ./configure: GNUTLS_LIBS="-lgnutls -lgcrypt" ./configure.ac: GNUTLS_LIBS="-lgnutls -lgcrypt" ./gnutls/local.h:#include <gcrypt.h> ./gnutls/secure.cpp: static int gcrypt_mutex_init(void **mp) ./gnutls/secure.cpp: static int gcrypt_mutex_destroy(void **mp) ./gnutls/secure.cpp: static int gcrypt_mutex_lock(void **mp) ./gnutls/secure.cpp: static int gcrypt_mutex_unlock(void **mp) ./gnutls/secure.cpp: static struct gcry_thread_cbs gcrypt_threading = { ./gnutls/secure.cpp: gcrypt_mutex_init, gcrypt_mutex_destroy, ./gnutls/secure.cpp: gcrypt_mutex_lock, gcrypt_mutex_unlock ./gnutls/secure.cpp: gcry_control(GCRYCTL_SET_THREAD_CBS, &gcrypt_threading); (In reply to comment #17) > Ок, I found the cause of this bug. > It's 3 level dependencu bug, i.e gnutls[nettle] not used/install libgcrypt; > but > gnutls[-nettle] does it. > It's build system bug ( since ancient times, when there was no support > nettle in gnutls) . > True, but only in part. :sigh: I wonder how many times I'll need to repeat myself. Yes, ucommon should have checked for gcrypt explicitly, even back when gnutls was using it exclusively. But that still doesn't answer the main question - is this locking mechanism still necessary while gnutls is using nettle ? (In reply to comment #18) > (In reply to comment #17) > > Ок, I found the cause of this bug. > > It's 3 level dependencu bug, i.e gnutls[nettle] not used/install libgcrypt; > > but > > gnutls[-nettle] does it. > > It's build system bug ( since ancient times, when there was no support > > nettle in gnutls) . > > > True, but only in part. > :sigh: I wonder how many times I'll need to repeat myself. > Yes, ucommon should have checked for gcrypt explicitly, even back when > gnutls was using it exclusively. But that still doesn't answer the main > question - is this locking mechanism still necessary while gnutls is using > nettle ? It's not only 'checked', it's explicitly include gcrypt headers, without an alternative. @comment 19: how else could it use i.e. gcry_control ? But I'm saying that it may not a situation of "closing the barn door after the horse runs away", but more like "close the *pigsty* door *before* the horse runs away" - the whole dance may now done just to show off, without having any effect on how the code runs. Just see NEWS for gnutls @Version 2.11.0. fixed in overlay, wait to commit in tree https://code.google.com/p/slepnoga/source/browse/#hg%2Fportage%2Fdev-libs%2Fucommon (In reply to comment #21) > fixed in overlay, wait to commit in tree > > https://code.google.com/p/slepnoga/source/browse/#hg%2Fportage%2Fdev- > libs%2Fucommon Looking at the fix, I can't help to think it's a "'add -j1' to `fix` parallel make problems" solution - yes, it makes the code build. Unfortunately, AFAICT ucommon doesn't have a public bugtracking system (cause I don't count one that requires signing up), so I can't tell whether this problem was reported/discussed upstream. ...to clarify, I've meant "one that requires signing up to search" (http://bugs.gnutelephony.org/). Anyway, upstream responded, that gcrypt is used for a bit more than thread locking of gnutls, but also that they were unaware of the changes in gnutls and that there might be a future release of ucommon that will use nettle instead of gcrypt. Fixed in next version, 6.0.3 in tree. |