gnutls ./configure will often fail when building in a ROOT, especially when cross-compiling because it doesn't take account of sysroot when checking for its library dependencies. It provides an array of configure options to set the prefixes instead. Needlessly complicated as usual but oh well. :) Adding the following fixes the problem. --with-libgcrypt-prefix=${EROOT}usr --with-libnettle-prefix=${EROOT}usr --with-libtasn1-prefix=${EROOT}usr --with-libpth-prefix=${EROOT}usr --with-libreadline-prefix=${EROOT}usr It doesn't seem to matter whether the libraries are being used or not so they need not be conditional. The whole ROOT vs EROOT thing confuses me but I think it needs to be EROOT in this case.
Actually scratch that. I think I screwed up my toolchain by mistake. I'll close this when I'm sure.
No wait, I was right the first time, my toolchain is fine and this really is an issue! *lol*
Check out gnutls-3.1.5-r1, reopen if more issues. Thanks!
Sorry to interfere, but this fix breaks my not-yet-published alternative to the multilib-portage overlay, and quite possibly the multilib-portage overlay itself. Unfortunately, I cannot reopen this bug myself due to insufficient permissions. The problem happens when compiling for ABI=x86, with all x86 dependencies already installed. Autoconf, when passed --with-libnettle-prefix=//usr (as you do), will search for libnettle only as /usr/lib/libnettle.so (with "/lib" after /usr being hardcoded and unchangeable). This is a general problem with the AC_LIB_HAVE_LINKFLAGS macro. For ABI=amd64, configure is smart enough to search in lib64 (it is special-cased), but it is not smart enough to look into lib32 in my case. End result: configure fails, because linking with the found library fails (it is for the wrong ABI). In my case, one of the config.log lines looks like this: configure:9349: x86_64-pc-linux-gnu-gcc -m32 -std=gnu99 -o conftest -O2 -pipe -I//usr/include -Wl,-O1 -Wl,--as-needed conftest.c //usr/lib/libnettle.so //usr/lib/libhogweed.so //usr/lib/libgmp.so -Wl,-rpath -Wl,//usr/lib >&5 Just in case, here is the relevant line from 3.1.5 config.log, and it correctly picks up the libdir from --libdir: configure:9349: x86_64-pc-linux-gnu-gcc -m32 -std=gnu99 -o conftest -O2 -pipe -Wl,-O1 -Wl,--as-needed conftest.c /usr/lib32/libnettle.so /usr/lib32/libhogweed.so /usr/lib32/libgmp.so -Wl,-rpath -Wl,/usr/lib32 >&5 IMHO the problem is that the configure script tries to link to the shared libraries by their full path. Instead, it should set the correct linker flags and just pass -lnettle -lhogweed -lgmp.
OK, I will revert this. Thank you for the detail explanation. The config scripts of these external components should have hard coded the libdir they compiled in. Can you determine which output wrong LDFLAGS at your machine?
Well, it cannot be really done... it does not use the -config scripts of packages... It relays on acl_libdirstem and of it to set it up internally, without override. It also handles only /lib and /lib64 schemes... See lib-prefix.m4::AC_LIB_PREPARE_MULTILIB Maybe adding: */lib64/ | */lib64 ) acl_libdirstem=lib64 ;; + */lib32/ | */lib32 ) acl_libdirstem=lib32 ;; Will resolve it.
James, Please take this to upstream, the package is broken for cross compile. It should not search for dependencies in the way it does. Any fix of us will probably break something else, and have maintenance costs. Thanks,
I was going to file a report upstream but I found that the problem is solely with AC_LIB_HAVE_LINKFLAGS and this actually originates from gnulib. gnutls bundles this unmodified. I also found this response by the author to a user reporting the same issue. http://lists.gnu.org/archive/html/bug-gnulib/2011-02/msg00010.html The short answer is --without-libnettle-prefix does the trick. Only this option is necessary because only this library is located using AC_LIB_HAVE_LINKFLAGS. I believe this would also work in Alexander's case. Could you please try it? wget suffers from the very same issue and requires --without-libgnutls-prefix --without-libssl-prefix. Assuming we go ahead with this, will you apply it to wget too or should I file another bug report?
(In reply to comment #8) > wget suffers from the very same issue and requires > --without-libgnutls-prefix --without-libssl-prefix. Assuming we go ahead > with this, will you apply it to wget too or should I file another bug report? Separate bug please.
(In reply to comment #8) > The short answer is --without-libnettle-prefix does the trick. Only this > option is necessary because only this library is located using > AC_LIB_HAVE_LINKFLAGS. I believe this would also work in Alexander's case. > Could you please try it? Alexander?
James, I think this should still be fixed upstream... but from experience fixing gnulib is taking years...
Hello, I am closing this, please work with upstream for decent cross compile support. Thanks, Alon
I am still affected by this issue and so are other judging by bug #438912. Also the libraries that gnutls uses has changed. It now bundles libnettle (boo!) but applies AC_LIB_HAVE_LINKFLAGS and friends to others (boo!). The options are... --without-libiconv-prefix --without-libintl-prefix --without-libpth-prefix --without-libpthread-prefix --without-librt-prefix --without-libz-prefix I'm CC'ing Alexander because I'd still very much like his input on this.
Sorry but I'd like to reopen this. Even after several years, this is still an issue and I'm seeing it in other GNU packages like guile too. I don't have the energy or the patience to take this upstream. Even if gnulib did eventually accept a fix, it would probably take months or even years for the changes to trickle down to the various projects. They would more likely tell us to just use the --without-*-prefix options because this gives us the behaviour we actually want. I did a diff of config.log with and without the options and the main differences were these. configure:51253: checking for libz -configure:51275: x86_64-pc-linux-gnu-gcc -o conftest -march=corei7 -O2 -pipe -Wl,-O1 -Wl,--as-needed conftest.c /usr/lib64/libz.so >&5 +configure:51275: x86_64-pc-linux-gnu-gcc -o conftest -march=corei7 -O2 -pipe -Wl,-O1 -Wl,--as-needed conftest.c -lz >&5 configure:51275: $? = 0 configure:51285: result: yes configure:51292: checking how to link with libz -configure:51294: result: /usr/lib64/libz.so +configure:51294: result: -lz -LIBZ='/usr/lib64/libz.so' -LIBZ_PREFIX='/usr' +LIBZ='-lz' +LIBZ_PREFIX='' -LTLIBZ='-L/usr/lib64 -lz' +LTLIBZ='-lz' As you can see, the --without-*-prefix options tell configure to stop trying to be clever and just trust the toolchain like most sensible software does. This is desirable for native, multilib, cross, and prefix situations. Unlike before, multilib is well established now and I was easily able to test that it doesn't break. Not all of the options are necessary on a typical system but all the --without-*-prefix options should be given to cover any exotic platforms. Please see the attached patch against 3.4.15 and 3.5.4, the latter currently being masked.
Created attachment 448626 [details, diff] Patch against 3.4.15 and 3.5.4
Preventing build system from doing clever tricks to rely solely the toolchain also benefits Prefix. Please consider committing this patch.
The options seem to vary a bit between releases. Just a suggestion but if you want to save yourself the bother of having to check them all the time, you could cheat by doing this. $("${S}"/configure --help | grep -o -e '--without-[^ ]*-prefix\b')
thanks! the --without-*-prefix is working in these versions, added.
