bug in libtool rpath setting for _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) (libtool 1.5.22)

Hi,

The stable libtool release has a bug in libtool.m4 that sets 
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) to '${wl}--rpath ${wl}$libdir'
by default instead of '${wl}-rpath ${wl}$libdir' (one less -). This causes 
the build failure seen at 
http://jhbuild.bxlug.be/builds/2006-12-12-0005/logs/evolution-data-server/#build

This was fixed in the development release two years ago:
http://cvs.savannah.gnu.org/viewcvs/libtool/libtool/m4/Attic/libtool.m4?r1=1.132&r2=1.133

--

-- 
# TRS-80              trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \
# UCC Wheel Member     http://trs80.ucc.asn.au/ #|  what squirrels do best     |
[ "There's nobody getting rich writing          ]|  -- Collect and hide your   |
[  software that I know of" -- Bill Gates, 1980 ]\  nuts." -- Acid Reflux #231 /

_______________________________________________
Bug-libtool mailing list
Bug-libtool <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: bug in libtool rpath setting for _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) (libtool 1.5.22)

Hello James,

Thanks for the report.

* James Andrewartha wrote on Wed, Dec 13, 2006 at 12:53:32AM CET:
> 
> The stable libtool release has a bug in libtool.m4 that sets 
> _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) to '${wl}--rpath ${wl}$libdir'
> by default instead of '${wl}-rpath ${wl}$libdir' (one less -). This causes 
> the build failure seen at 
> http://jhbuild.bxlug.be/builds/2006-12-12-0005/logs/evolution-data-server/#build
> 
> This was fixed in the development release two years ago:

Yes, but we never knew or thought it was a necessity, we fixed it for
consistency only, thinking that ld accepts both -rpath and --rpath:
<http://lists.gnu.org/archive/html/libtool-patches/2004-11/msg00039.html>

And if you look closer at the build log, you'll find earlier link
command lines that succeed with --rpath.  So the failure is of a
different nature, but it does look like it could be a libtool bug.
Where are libnss3.so, libsmime3.so, libssl3.so, and libsoftokn3.so
located?  Could you rerun 'make' non-parallel so we see which link
is actually failing?

Could you post
  ./libtool --config

for the libtool script generated by the build, from the
/scratch/gnometinderbox/jhautobuild/cvs/evolution-data-server directory?

Re: bug in libtool rpath setting for _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) (libtool 1.5.22)

On Wed, 13 Dec 2006, Ralf Wildenhues wrote:

> * James Andrewartha wrote on Wed, Dec 13, 2006 at 12:53:32AM CET:
>>
>> The stable libtool release has a bug in libtool.m4 that sets
>> _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) to '${wl}--rpath ${wl}$libdir'
>> by default instead of '${wl}-rpath ${wl}$libdir' (one less -). This causes
>> the build failure seen at
>> http://jhbuild.bxlug.be/builds/2006-12-12-0005/logs/evolution-data-server/#build
>>
>> This was fixed in the development release two years ago:
>
> Yes, but we never knew or thought it was a necessity, we fixed it for
> consistency only, thinking that ld accepts both -rpath and --rpath:
> <http://lists.gnu.org/archive/html/libtool-patches/2004-11/msg00039.html>
>
> And if you look closer at the build log, you'll find earlier link
> command lines that succeed with --rpath.  So the failure is of a
> different nature, but it does look like it could be a libtool bug.
> Where are libnss3.so, libsmime3.so, libssl3.so, and libsoftokn3.so
> located?  Could you rerun 'make' non-parallel so we see which link
> is actually failing?

They're located in 
/scratch/gnometinderbox/jhautobuild/build-output/lib/xulrunner-1.8.1.1
which is included via -L. pkg-config --libs xulrunner-nspr returns:
-L/scratch/gnometinderbox/jhautobuild/build-output/lib/xulrunner-1.8.1.1 -lplds4 -lplc4
-lnspr4 -lpthread -ldl

failing build:

Re: bug in libtool rpath setting for _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) (libtool 1.5.22)

Hello James,

* James Andrewartha wrote on Wed, Dec 13, 2006 at 05:23:01PM CET:
> On Wed, 13 Dec 2006, Ralf Wildenhues wrote:
> >
> > Where are libnss3.so, libsmime3.so, libssl3.so, and libsoftokn3.so
> > located?  Could you rerun 'make' non-parallel so we see which link
> > is actually failing?
> 
> They're located in 
> /scratch/gnometinderbox/jhautobuild/build-output/lib/xulrunner-1.8.1.1
> which is included via -L. pkg-config --libs xulrunner-nspr returns:
> -L/scratch/gnometinderbox/jhautobuild/build-output/lib/xulrunner-1.8.1.1 -lplds4 -lplc4
-lnspr4 -lpthread -ldl

Your libtool has link_all_deplibs=no (see the --config output).  This
shows that it's Debian's modified libtool.  It avoid linking against
indirect dependencies.  This change has not made it into GNU Libtool
because it has bugs, and also because it has some different semantics
which would need to be documented.  From the information you posted,
both of these alternative possibilities exist:

1)
You cannot be sure anymore that a library (or program) links against the
dependencies of dependent libraries directly.  So if you need those
depdepls (if you allow me to call them that way), then with Debian's
libtool you need to specify them explicitly on the command line.

2)
If you do not need them in your program, then you just observe a known

Re: bug in libtool rpath setting for _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) (libtool 1.5.22)

On Fri, 15 Dec 2006, Ralf Wildenhues wrote:

> Your libtool has link_all_deplibs=no (see the --config output).  This
> shows that it's Debian's modified libtool.  It avoid linking against
> indirect dependencies.  This change has not made it into GNU Libtool
> because it has bugs, and also because it has some different semantics
> which would need to be documented.  From the information you posted,
> both of these alternative possibilities exist:
>
> 1)
> You cannot be sure anymore that a library (or program) links against the
> dependencies of dependent libraries directly.  So if you need those
> depdepls (if you allow me to call them that way), then with Debian's
> libtool you need to specify them explicitly on the command line.
>
> 2)
> If you do not need them in your program, then you just observe a known
> bug in Debian's libtool: while linking against uninstalled libraries,
> the paths to depdepls are not found correctly, because libtool does not
> walk the dependency path.
>
> I think you are seeing (2).  In that case you could work around the
> issue by linking directly against the needed libs, by adding these
> arguments to the link (if you use Automake, add them to
> create_account_LDADD):
>  /scratch/gnometinderbox/jhautobuild/build-output/lib/xulrunner-1.8.1.1/libnss3.la
>  /scratch/gnometinderbox/jhautobuild/build-output/lib/xulrunner-1.8.1.1/libsmime3.la
>  /scratch/gnometinderbox/jhautobuild/build-output/lib/xulrunner-1.8.1.1/libssl3.la
>  /scratch/gnometinderbox/jhautobuild/build-output/lib/xulrunner-1.8.1.1/libsoftokn3.la
>

help plz

_______________________________________________
Bug-libtool mailing list
Bug-libtool <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: help plz

Hello Mehul,

* mehul shah wrote on Tue, Dec 19, 2006 at 03:37:09PM CET:
> 
> libtool: unrecognized option `--tag=CXX'
> Try `libtool --help' for more information.

This error comes from a Libtool release older than 1.5.  Current is
1.5.22.  You need to ensure that a newer libtool is used.

Now, most of the time, software packages come with the libtool machinery
packed inside the package -- the libtool script is then built at the end
of the 'configure' step.  If that's the case for the package you're
compiling, then it seems that it has a bug.  If not, then you could
upgrade your system libtool, or read the package's documentation that
probably has details about a requirement for an external libtool.

Hope that helps.

Cheers,
Ralf

Re: help plz

_______________________________________________
Bug-libtool mailing list
Bug-libtool <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: help plz

_______________________________________________
Bug-libtool mailing list
Bug-libtool <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

makeC++SharedLib_r not used on AIX

Hi,

for building a C++-library on AIX there is a script makeC++SharedLib or 
makeC++SharedLib_r in multithreaded apps, which according to IBM have to be 
used. Otherwise static initializers are not called.

I ran into this problem and prepared a testcase, which confirms this. I 
modified the tagdemo to use a static std::string-object to print the in the 
library. On AIX the string is empty.

You can find my modified version of tagdemo on 
http://www.tntnet.org/tagdemo-0.1.tar.gz and the output on AIX at 
http://www.tntnet.org/tagdemo.out.

There is a empty line instead of the message "** This is libfoo (tagdemo) **" 
in the output.

Tommi