On one system (amd64) I could successfully update libgcrypt from 1.5.4 to 1.6.3-r4 but on all others (amd64, x86) its it failing with the following error: /bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -O2 -pipe -march=native -fvisibility=hidden -Wall -Wl,-O1 -Wl,--as-needed -o mpicalc mpicalc-mpicalc.o libgcrypt.la -lgpg-error libtool: link: x86_64-pc-linux-gnu-gcc -DSTANDALONE -O2 -pipe -march=native -fvisibility=hidden -Wall -Wl,-O1 -Wl,--as-needed -o hmac256 hmac256-hmac256.o libtool: link: x86_64-pc-linux-gnu-gcc -O2 -pipe -march=native -fvisibility=hidden -Wall -Wl,-O1 -Wl,--as-needed -o .libs/mpicalc mpicalc-mpicalc.o ./.libs/libgcrypt.so -lgpg-error ./.libs/libgcrypt.so: undefined reference to `_gcry_USE_THE_UNDERSCORED_FUNCTION' collect2: error: ld returned 1 exit status Makefile:719: recipe for target 'mpicalc' failed make[2]: *** [mpicalc] Error 1 make[2]: Leaving directory '/var/tmp/portage/dev-libs/libgcrypt-1.6.3-r4/work/libgcrypt-1.6.3-abi_x86_64.amd64/src' Makefile:479: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/var/tmp/portage/dev-libs/libgcrypt-1.6.3-r4/work/libgcrypt-1.6.3-abi_x86_64.amd64' Makefile:410: recipe for target 'all' failed make: *** [all] Error 2 Reproducible: Always
Created attachment 411704 [details] build.log
Created attachment 411706 [details] emerge --info
It looks like the cause could be ./libgcrypt-1.6.3/random/rndegd.c making use of gcry_strdup() and gcry_xmalloc() instead of their _gcry_* counterparts. Though that does not explain why it compiles on some systems. There seems to be a configure setting impacting selection of randomness source files to be used. The only distinction that may have an impact is that the failing systems are inside namespaces with reduced /dev/ content (no /dev/random, just /dev/urandom). Does this trigger wrong source file selection for random functions? Symlinking /dev/urandom to /dev/random fixes compilation.
(In reply to Bruno from comment #3) > The only distinction that may have an impact is that the failing systems are > inside namespaces with reduced /dev/ content (no /dev/random, just > /dev/urandom). > > Does this trigger wrong source file selection for random functions? > > Symlinking /dev/urandom to /dev/random fixes compilation. please add /dev/random, it is a must for crypto to work properly. reducing /dev is not something we [should] support.
(In reply to Alon Bar-Lev from comment #4) > (In reply to Bruno from comment #3) > > The only distinction that may have an impact is that the failing systems are > > inside namespaces with reduced /dev/ content (no /dev/random, just > > /dev/urandom). > > > > Does this trigger wrong source file selection for random functions? > > > > Symlinking /dev/urandom to /dev/random fixes compilation. > > please add /dev/random, it is a must for crypto to work properly. reducing > /dev is not something we [should] support. Agreed, closing this as wontfix
(In reply to Kristian Fiskerstrand from comment #5) > (In reply to Alon Bar-Lev from comment #4) > > (In reply to Bruno from comment #3) > > > The only distinction that may have an impact is that the failing systems are > > > inside namespaces with reduced /dev/ content (no /dev/random, just > > > /dev/urandom). > > > > > > Does this trigger wrong source file selection for random functions? > > > > > > Symlinking /dev/urandom to /dev/random fixes compilation. > > > > please add /dev/random, it is a must for crypto to work properly. reducing > > /dev is not something we [should] support. > > Agreed, closing this as wontfix I can agree with the "wontfix" if it is for the absence of /dev/random. On the other hand, there still is a BUG in the code in file libgcrypt-1.6.3/random/rndegd.c as it's libgcrypt internal file using external API it should not be using. That part should definitely get fixed upstream. The selection of randomness code to be built might want to get improved with proper bail-out if some pre-requisite is missing (selection happens via configure so failure should happen at that time). So forwarding the bug for undefined reference to upstream should still be done.
(In reply to Bruno from comment #6) > So forwarding the bug for undefined reference to upstream should still be > done. please do.
