Subject: Re: bug#8441: Patches making libtool-2.4-1 build under GNU/Hurd

From: Svante Signell <[email-masked]>
Date: Thu, 07 Apr 2011 20:20:55 +0200

On Thu, 2011-04-07 at 20:06 +0200, Ralf Wildenhues wrote:
> Hi Svante,
> 
> * Svante Signell wrote on Thu, Apr 07, 2011 at 06:24:20PM CEST:
> > The first defines shlibpath_overrides_runpath for gnu.
> 
> Is this always the correct setting?  binutils can be configured with
> either as default.
> 
> > # shlibpath_overrides_runpath is set to 'unknown' in libtool.m4
> 
> Oh.  Then you have a good point.  This should go upstream.

OK!

> > # and not defined under $host_os ="gnu"
> > # This patch make the tests/*demo* run.
> > --- libtool-2.4/libltdt/m4/libtool.m4.orig	2011-02-03 21:33:56.000000000 +0100
> > +++ libtool-2.4/libltdl/m4/libtool.m4	2011-02-03 21:43:46.000000000 +0100
> > @@ -2325,6 +2325,7 @@
> >    library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}${major} ${libname}${shared_ext}'
> >    soname_spec='${libname}${release}${shared_ext}$major'
> >    shlibpath_var=LD_LIBRARY_PATH
> > +  shlibpath_overrides_runpath=no
> >    hardcode_into_libs=yes
> >    ;;
> 
> > # This test is broken for hurd-i386
> > # Skip for $host_os = "gnu", since max_cmd_len=-1 to indicate that
> > # max_cmd_len is not limited under GNU Hurd.
> > #
> > --- libtool-2.4/tests/cmdline_wrap.at.orig	2010-05-20 23:18:41.000000000 +0200
> > +++ libtool-2.4/tests/cmdline_wrap.at	2011-02-06 11:08:29.000000000 +0100
> > @@ -30,6 +30,9 @@
> >  m4_ifdef([AT_CAPTURE_FILE],
> >  [AT_CAPTURE_FILE([testsuite.log])])
> >  
> > +# Setting low max_cmd_len on "hurd-386" does not make sense"
> > +AT_CHECK([if test "$host_os" == "gnu" ; then exit 77; fi])
> 
> Please use = not ==, the former is Posix test, the latter bash-specific.

OK, do you want me to send an update?

> Does this test actually fail on hurd-i386, or is this just because you
> consider it wasted time?  In the former case, please send the patch
> upstream but also show a cut-n-paste of the failing test log.

Yes, this test fails without the patch. I'll build an unpatched version
and submit the failing test log. BTW: Where is upstream, is
[email-masked] sufficient?

Thanks,
Svante