[Buildroot] [PATCH] gnutls: Fix search path for libgcrypt

[Buildroot] [PATCH] gnutls: Fix search path for libgcrypt

[Arnout Vandecappelle]

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(-)

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
 
-- 
tg: (babd953..) t/gnutls (depends on: master)

[Buildroot] [PATCH] gnutls: Fix search path for libgcrypt

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH] gnutls: Fix search path for libgcrypt

[Arnout Vandecappelle]

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

-- 
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

[Buildroot] [PATCH] gnutls: Fix search path for libgcrypt

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH] gnutls: Fix search path for libgcrypt

[Peter Korsgaard]

>>>>> "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?

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] gnutls: Fix search path for libgcrypt

[Arnout Vandecappelle]

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 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

[Buildroot] [PATCH] gnutls: Fix search path for libgcrypt

[Peter Korsgaard]

>>>>> "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.

-- 
Bye, Peter Korsgaard