Created attachment 326538 [details] build log I have tested it with all USE flag combinations. It fails when you try to compile it _WITHOUT_ ssl USE flag and _WITH_ gnutls USE flag at the same time. # emerge --info Portage 2.1.11.9 (default/linux/amd64/10.0, gcc-4.5.4, glibc-2.15-r3, 3.4.9-gentoo x86_64) ================================================================= System uname: Linux-3.4.9-gentoo-x86_64-AMD_Sempron-tm-_Processor_3800+-with-gentoo-2.1 Timestamp of tree: Sun, 14 Oct 2012 11:30:01 +0000 app-shells/bash: 4.2_p37 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.3-r2, 3.2.3 dev-util/cmake: 2.8.9 dev-util/pkgconfig: 0.27.1 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.9.8.4 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.11.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.5.4 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r3 sys-kernel/linux-headers: 3.4-r2 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo peratu ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe -g0 -Wno-pointer-sign" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=k8 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs collision-protect config-protect-if-modified distlocks ebuild-locks fixlafiles multilib-strict news parallel-fetch parse-eapi-ebuild-head protect-owned sandbox sfperms split-log strict test unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="es_ES.utf8" LC_ALL="C" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu" LINGUAS="es" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_COMPRESS="" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowext acl amd64 berkdb bzip2 cli cracklib crypt cxx dri fortran gdbm gpm iconv mmx mmxext modules mudflap multilib ncurses nls nptl openmp pam pcre pppd readline session sse sse2 ssl tcpd unicode zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="es" PHP_TARGETS="php5-3" PYTHON_TARGETS="python3_2 python2_7" RUBY_TARGETS="ruby19" USERLAND="GNU" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
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.
