bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libtool-2.2.6a breaks build of guile-1.8.5, libtool-1.5.26 is OK


From: Sergei Steshenko
Subject: Re: libtool-2.2.6a breaks build of guile-1.8.5, libtool-1.5.26 is OK
Date: Mon, 10 Nov 2008 14:26:45 -0800 (PST)



--- On Mon, 11/10/08, Ralf Wildenhues <address@hidden> wrote:

> From: Ralf Wildenhues <address@hidden>
> Subject: Re: libtool-2.2.6a breaks build of guile-1.8.5, libtool-1.5.26 is OK
> To: "Sergei Steshenko" <address@hidden>
> Cc: "Bob Friesenhahn" <address@hidden>, "Libtool Bugs List" <address@hidden>
> Date: Monday, November 10, 2008, 1:39 PM

[snip]

> 
> I should note that I had to employ some force in order to
> get guile to
> use updated autotools.  I used something like this:
> 
>   autoreconf -vif       # to let libtoolize do its job in
> subdirs
>                         # but this fails in toplevel due to
> some error
>   rm -f ltmain.sh
>   cp $libtool_install_tree/share/libtool/config/ltmain.sh
> build-aux/ltmain.sh
>   LIBTOOLIZE=true autoreconf -vif --no-recursive #
> regenerate the toplevel
> 
> Hope that helps.
> 
> Cheers,
> Ralf

Do I reed you correctly, i.e. can your statement be expressed this way:

guile can _not_ be built by libtool-2.2.6a out of the box using the
standard

./configure
make

procedure ?


Regarding your assumption about mixed libtool version - again, _very_
unlikely.

This is because whenever a target is built, it is built _from scratch_,
i.e. the old build directory - in this case

build/guile-1.8.5

is _completely_ removed using "\rm -rf build/guile-1.8.5", then the tarball
is again unpacked using "cd build; tar zxvf guile-1.8.5.tar.gz", and only
then the standard

./configure
make
...

procedure is applied.

So, for your hypothesis to hold my tool needs to be stubborn enough to
do something libtool-1.5.26-specific when it is told to use libtool-2.2.6a,
and as you could see in the command line I've provided, there is no 
reference to libtool-1.5.26.

Obviously, the tool behaves the same way WRT all targets it builds, so, had
the tool been that stubborn, I would have noticed this behavior on
other targets - not the case.

Regarding "nm .libs/guileS.o" - yes, only 'lt_preloaded_symbols' is 
defined:

"
pwd; nm .libs/guileS.o
/mnt/sdb8/sergei/AFSWD_debug/build/guile-1.8.5.libtool-2.2.6a/libguile
00000000 R lt_preloaded_symbols
".

Regarding ltmain.sh - it is _the_ culprit -  I have manually unpacked
guile-1.8.5.tar.gz in a clean directory, and this is what I see:

"
pwd; find . -name ltmain.sh; grep VERSION= `find . -name ltmain.sh`
/mnt/sdb8/sergei/AFSWD_debug/build/tmp
./guile-1.8.5/guile-readline/ltmain.sh
./guile-1.8.5/build-aux/ltmain.sh
./guile-1.8.5/guile-readline/ltmain.sh:VERSION=1.5.26
./guile-1.8.5/build-aux/ltmain.sh:VERSION=1.5.26
"

- so what does _my_ tool have to do with the fact that guile-1.8.5 comes
with libtool "VERSION=1.5.26" and relies on it ?

Don't you think it's a bug in guile-1.8.5 ?

Thanks for helping to dig this.


Regards,
  Sergei.



      




reply via email to

[Prev in Thread] Current Thread [Next in Thread]