| Message ID | 1336847275-21899-1-git-send-email-arnout@mind.be |
|---|---|
| State | Changes Requested |
| Headers | show |
Hello, Le Sat, 12 May 2012 20:27:55 +0200, "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be> a écrit : > 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/ > > Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> 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
On 05/12/12 21:07, Thomas Petazzoni wrote: > Le Sat, 12 May 2012 20:27:55 +0200, > "Arnout Vandecappelle (Essensium/Mind)"<arnout@mind.be> a écrit : > >> > 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)<arnout@mind.be> > 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. > 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. > > 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. 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
Le Sat, 12 May 2012 22:07:16 +0200, Arnout Vandecappelle <arnout@mind.be> a écrit : > > 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? It should yes. I will test your patch and see if it improves the situation. > 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 :-( > 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
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> 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?
On 05/14/12 21:14, Peter Korsgaard wrote: >>>>>> "Arnout" == Arnout Vandecappelle<arnout@mind.be> 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
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> 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. >> 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.
diff --git a/package/gnutls/gnutls.mk b/package/gnutls/gnutls.mk index ce570d5..fb2ba7d 100644 --- a/package/gnutls/gnutls.mk +++ b/package/gnutls/gnutls.mk @@ -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
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/ Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> --- package/gnutls/gnutls.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)