gnutls: Fix search path for libgcrypt
PATCH 1/1 gnutls: Fix search path for libgcrypt
In some configurations, the --with-libgcrypt-prefix configure option causes the default library search path to be disabled completely, so the compiler can't find libc etc.
Fixes http://autobuild.buildroot.net/results/52a227e8a8723b7914a37d9b3519da5fd2a2844a/
--- package/gnutls/gnutls.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
package/gnutls/gnutls.mk +1 -1
@@ -8,7 +8,7 @@ GNUTLS_VERSION = 2.12.18 GNUTLS_SOURCE = gnutls-$(GNUTLS_VERSION).tar.bz2 GNUTLS_SITE = $(BR2_GNU_MIRROR)/gnutls GNUTLS_DEPENDENCIES = host-pkg-config libgcrypt -GNUTLS_CONF_OPT = --with-libgcrypt --with-libgcrypt-prefix=$(STAGING_DIR)/usr \ +GNUTLS_CONF_OPT = --with-libgcrypt \ --without-p11-kit GNUTLS_INSTALL_STAGING = YES
Signature · 1 line
tg: (babd953..) t/gnutls (depends on: master)
PATCH 1/1 gnutls: Fix search path for libgcrypt
Hello,
Le Sat, 12 May 2012 20:27:55 +0200,
"Arnout Vandecappelle (Essensium/Mind)" <[email protected]> a ?crit :
Quoted 7 lines
In some configurations, the --with-libgcrypt-prefix configure option causes the default library search path to be disabled completely, so the compiler can't find libc etc.
Fixes http://autobuild.buildroot.net/results/52a227e8a8723b7914a37d9b3519da5fd2a2844a/
Are you sure it fixes the problem?
Last WE, I started investigating the problem, and found out that just compiling gnutls wasn't enough to reproduce the problem. The problem was starting to occur when libintl was built before libgcrypt. In this case, libgcrypt.la had -lintl in its dependencies, and in turn, libintl.la had -lc in its dependencies. Then, libtool expands this -lc into the full path to libc.so.
However, libc.so is a linker script which contains a reference to /lib/libc.so.0. And unfortunately, there is a binutils bug that makes it behave differently:
* If a linker script is referenced using -lc, then it correctly prepends the paths in the linker script by the sysroot path;
* If a linker script is referenced using its full path (as is done by libtool), then binutils do not prepend the paths in the linker script by the sysroot path, which leads the gnutls ./configure to try to link against /lib/libc.so.0, which obviously doesn't exist.
Gustavo has patches for binutils that solve this bug, but the problem remains for external toolchains. I am not sure how to fix the problem properly.
Best regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 gnutls: Fix search path for libgcrypt
Quoted 11 lines · Thomas Petazzoni
Le Sat, 12 May 2012 20:27:55 +0200,
"Arnout Vandecappelle (Essensium/Mind)"<[email protected]> a ?crit :Quoted 7 lines
Quoted 7 lines
In some configurations, the --with-libgcrypt-prefix configure option causes the default library search path to be disabled completely, so the compiler can't find libc etc.
Fixeshttp://autobuild.buildroot.net/results/52a227e8a8723b7914a37d9b3519da5fd2a2844a/
Signed-off-by Arnout Vandecappelle (Essensium/Mind)<[email protected]>Are you sure it fixes the problem?
Alas, no. I built it and it failed. Then I patched it, rebuilt it and it worked.
I guess make decided to reorder things for whatever reason.
Quoted 6 lines
Last WE, I started investigating the problem, and found out that just compiling gnutls wasn't enough to reproduce the problem. The problem was starting to occur when libintl was built before libgcrypt. In this case, libgcrypt.la had -lintl in its dependencies, and in turn, libintl.la had -lc in its dependencies. Then, libtool expands this -lc into the full path to libc.so.
After the patch, that doesn't seem to make a difference for me.
I did the following after a successful build:
make libgcrypt-dirclean gnutls-dirclean; make
That succeeded. Then I did
rm -f {staging,target}/{usr/,}lib/*intl*
rm -rf build/gettext*
make libgpg-error-dirclean libgcrypt-dirclean gnutls-dirclean make gnutls; make
That still succeeded. (It looks like libgpg-error is missing a
dependency on gettext/libintl, though.) And finally, just to be sure:
rm -f {staging,target}/{usr/,}lib/*intl*
rm -rf build/gettext*
make libgpg-error-dirclean libgcrypt-dirclean gnutls-dirclean make libintl; make
Also succeeded. That pretty much covers the libintl dependency,
right?
This is BTW from one of the broken configs reported in the
autobuild, from which I also had to remove some more broken packages (ltp-testsuite, ndisc6). It's a generic powerpc internal toolchain.
Quoted 8 lines
However, libc.so is a linker script which contains a reference to
/lib/libc.so.0. And unfortunately, there is a binutils bug that makes it behave differently:* If a linker script is referenced using -lc, then it correctly
prepends the paths in the linker script by the sysroot path;
Quoted 8 lines
* If a linker script is referenced using its full path (as is done by libtool), then binutils do not prepend the paths in the linker script by the sysroot path, which leads the gnutls ./configure to try to link against
/lib/libc.so.0, which obviously doesn't exist.Gustavo has patches for binutils that solve this bug, but the problem remains for external toolchains. I am not sure how to fix the problem properly.
A heavy-handed approach would be to generate the patched
binutils for known-to-be-faulty external toolchains.
A simple approach would be to use the patched binutils on the test
machines :-)
BTW, how come this problem doesn't manifest itself more often?
There are many packages with -lintl in their .la dependencies, so all of them should fail regularly, no?
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286540 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
PATCH 1/1 gnutls: Fix search path for libgcrypt
Le Sat, 12 May 2012 22:07:16 +0200,
Arnout Vandecappelle <[email protected]> a ?crit :
Quoted 24 lines
Quoted 6 lines
Last WE, I started investigating the problem, and found out that just compiling gnutls wasn't enough to reproduce the problem. The problem was starting to occur when libintl was built before libgcrypt. In this case, libgcrypt.la had -lintl in its dependencies, and in turn, libintl.la had -lc in its dependencies. Then, libtool expands this -lc into the full path to libc.so.
After the patch, that doesn't seem to make a difference for me.
I did the following after a successful build:
make libgcrypt-dirclean gnutls-dirclean; makeThat succeeded. Then I did
rm -f {staging,target}/{usr/,}lib/*intl*
rm -rf build/gettext*
make libgpg-error-dirclean libgcrypt-dirclean gnutls-dirclean make gnutls; makeThat still succeeded. (It looks like libgpg-error is missing a
dependency on gettext/libintl, though.) And finally, just to be sure:
rm -f {staging,target}/{usr/,}lib/*intl*
rm -rf build/gettext*
make libgpg-error-dirclean libgcrypt-dirclean gnutls-dirclean make libintl; make
Quoted 2 lines
Also succeeded. That pretty much covers the libintl dependency,
right?
It should yes. I will test your patch and see if it improves the situation.
Quoted 5 lines
A heavy-handed approach would be to generate the patched
binutils for known-to-be-faulty external toolchains.A simple approach would be to use the patched binutils on the test
machines :-)
None of these approaches are really easy to do, unfortunately :-(
Quoted 3 lines
BTW, how come this problem doesn't manifest itself more often?
There are many packages with -lintl in their .la dependencies, so all of them should fail regularly, no?
That's a good question indeed.
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 gnutls: Fix search path for libgcrypt
In reply to Arnout VandecappelleQuoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle <[email protected]> writes:
Hi,
Arnout> This is BTW from one of the broken configs reported in the Arnout> autobuild, from which I also had to remove some more broken Arnout> packages (ltp-testsuite, ndisc6). It's a generic powerpc internal Arnout> toolchain.
ltp-testsuite is known to be broken with the default uClibc config, but I wasn't aware of any ndisc6 issues. What exactly goes wrong?
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 gnutls: Fix search path for libgcrypt
Quoted 11 lines · Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle<[email protected]> writes:
Hi,
Arnout> This is BTW from one of the broken configs reported in the
Arnout> autobuild, from which I also had to remove some more broken Arnout> packages (ltp-testsuite, ndisc6). It's a generic powerpc internal Arnout> toolchain.ltp-testsuite is known to be broken with the default uClibc config, but I wasn't aware of any ndisc6 issues. What exactly goes wrong?
It's a gettext issue. I haven't looked at it because I was fixing something else,
and because gettext anyway had patches pending.
There are plenty of failures in autobuild, e.g.
http://autobuild.buildroot.net/results/1405f403f53624667c3d104a4e8f0c070501a639/
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286540 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
PATCH 1/1 gnutls: Fix search path for libgcrypt
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle <[email protected]> writes:
Hi,
Arnout> This is BTW from one of the broken configs reported in the Arnout> autobuild, from which I also had to remove some more broken Arnout> packages (ltp-testsuite, ndisc6). It's a generic powerpc Arnout> internal toolchain.
Quoted 2 lines
Quoted 2 lines
ltp-testsuite is known to be broken with the default uClibc config, but I wasn't aware of any ndisc6 issues. What exactly goes wrong?
Arnout> It's a gettext issue. I haven't looked at it because I was
Arnout> fixing something else, and because gettext anyway had patches Arnout> pending.
Thanks, fixed.
Signature · 1 line
Bye, Peter Korsgaard