headers
Ralf Wildenhues | 2 Jan 2006 09:33
Picon
Picon

Re: libtool 1.5.22 -- bug in LT_DLMUTEX_GETERROR()

Hi Alexis,

* Alexis Wilke wrote on Sat, Dec 31, 2005 at 08:04:05AM CET:
> 
> There is a really bad bug in LT_DLMUTEX_GETERROR() which checks if the
> lt_dlmutex_seterror_func [see SET] instead of the lt_dlmutex_geterror_func
> [see, here GET].

Thanks for this bug report.  I have applied this patch to branch-1-5 to
fix the issue.

Please note that the locking interfaces of libltdl are deprecated and
will be removed in libtool 2.0, because of various issues with them
(one of them being that they do not work correctly on all systems).

Cheers,
Ralf

2006-01-02  Alexis Wilke  <alexis_wilke <at> yahoo.com>

	* libltdl/ltdl.c (LT_DLMUTEX_GETERROR): check if
	`lt_dlmutex_geterror_func' is set instead of
	`lt_dlmutex_seterror_func'.

Index: libltdl/ltdl.c
===================================================================
RCS file: /cvsroot/libtool/libtool/libltdl/ltdl.c,v
retrieving revision 1.174.2.20
diff -u -r1.174.2.20 ltdl.c
--- libltdl/ltdl.c	13 Oct 2005 04:48:50 -0000	1.174.2.20
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ralf Wildenhues | 9 Jan 2006 00:00
Picon
Picon

Re: Libtool problem with shared lib in non-standard directory

Hi Marcel,

* Marcel Loose wrote on Thu, Jan 05, 2006 at 12:31:35PM CET:
> 
> I encountered a problem where libtool does not add a -rpath to all the
> libs it adds on the link line. I'll try to describe the problem.
> 
> I have two packages that are developed in-house, let's call them A and
> B. Package B depends on the (static) library of package A. Package A
> depends on a shared third party library that is installed in a
> non-standard directory (e.g. /non/standard/lib).
> 
> Now the following problem arises. When I build an executable from
> package B, libtool adds the libraries that package A depends upon in
> the link command. One of these libs is, of course, the third party lib
> that is installed in /non/standard/lib. The link command does contain
> a -L/non/standard/lib specification, but it does not contain a
> -Wl,-rpath,/non/standard/lib specification. As a result, any
> executable from package B cannot be run unless the user explicitily
> adds /non/standard/lib to its LD_LIBRARY_PATH, which is IMHO
> undesirable.

Thanks for this bug report.  It would fit better on the bug-libtool
mailing list, so I'm Cc:ing there.  Please remove the automake list
from followups.

Please state your operating system this happens on, the exact libtool
version used, and show both the link line (libtool --mode=link ...)
and what libtool outputs.  Also, the compiler used, and possibly
`./libtool --config' would be useful.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Han-Wen Nienhuys | 9 Jan 2006 13:08
Picon
Picon
Favicon

linking source dir .la's links in build system libraries


Hi,

- using libtool 1.5.20
- cross building on darwin 7 (PPC/MacOS 10.3) for a linux/x86/glibc2.2 
target.
- building GUILE and gettext

The following happens: the packages contain libA and libB, where libB 
depends on libA.

During install time, the relink step of libB.la tries to link in

    ../libA/libA.la

libA.la contains "libdir=/usr/lib"

libtool then introduces -L/usr/lib/ on the command line.  This has the 
effect of trying to link various libraries from the build system 
(/usr/lib/libgcc.a, /usr/lib/libltdl.a) from the build system, which 
breaks, or even more worrying, it might succeed on some platforms.

our current workaround is to edit the *.la scripts prior to install, 
substituting "<builddir>/.libs" into the libdir variable.

An example session and --config output is attached.

--

-- 
  Han-Wen Nienhuys - hanwen <at> xs4all.nl - http://www.xs4all.nl/~hanwen
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ralf Wildenhues | 9 Jan 2006 17:30
Picon
Picon

Re: linking source dir .la's links in build system libraries

Hi Han-Wen,

* Han-Wen Nienhuys wrote on Mon, Jan 09, 2006 at 01:08:41PM CET:
> 
> - using libtool 1.5.20
> - cross building on darwin 7 (PPC/MacOS 10.3) for a linux/x86/glibc2.2 
> target.
> - building GUILE and gettext
> 
> The following happens: the packages contain libA and libB, where libB 
> depends on libA.
> 
> During install time, the relink step of libB.la tries to link in
> 
>    ../libA/libA.la
> 
> libA.la contains "libdir=/usr/lib"
> 
> libtool then introduces -L/usr/lib/ on the command line.  This has the 
> effect of trying to link various libraries from the build system 
> (/usr/lib/libgcc.a, /usr/lib/libltdl.a) from the build system, which 
> breaks, or even more worrying, it might succeed on some platforms.

Please post config.log, packed (perferably .bzip2 or .gz).
I would like to see how you configure, and whether more oddities show up
in a cross compile.

Thank you,
Ralf
(Continue reading)

Permalink | Reply | 1 comment |
headers
Han-Wen Nienhuys | 10 Jan 2006 03:40
Picon
Picon
Favicon

Re: linking source dir .la's links in build system libraries

Ralf Wildenhues wrote:
> Hi Han-Wen,
> 
> * Han-Wen Nienhuys wrote on Mon, Jan 09, 2006 at 01:08:41PM CET:
> 
>>- using libtool 1.5.20
>>- cross building on darwin 7 (PPC/MacOS 10.3) for a linux/x86/glibc2.2 
>>target.
>>- building GUILE and gettext
>>
>>The following happens: the packages contain libA and libB, where libB 
>>depends on libA.
>>
>>During install time, the relink step of libB.la tries to link in
>>
>>   ../libA/libA.la
>>
>>libA.la contains "libdir=/usr/lib"
>>
>>libtool then introduces -L/usr/lib/ on the command line.  This has the 
>>effect of trying to link various libraries from the build system 
>>(/usr/lib/libgcc.a, /usr/lib/libltdl.a) from the build system, which 
>>breaks, or even more worrying, it might succeed on some platforms.
> 
> 
> Please post config.log, packed (perferably .bzip2 or .gz).
> I would like to see how you configure, and whether more oddities show up
> in a cross compile.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Haubenwallner | 11 Jan 2006 11:24
Picon

libtool & aix & g++ & pthread

Hi,

using libtool with aix & g++ & pthread seems to be one of the
worst combinations one can think of...

What i have:

powerpc-ibm-aix5.2.0.0
gcc-3.4.4
libtool-1.5.20 (initially without, then with some gentoo patches)
CFLAGS=-pthread
CXXFLAGS=-pthread
LDFLAGS=-Wl,-brtl

What my problem is:

gcc provides separate libstdc++.{a,la} for use with pthread and without.
When linking with libtool & g++ & pthread, i end up with an executable
depending on the non-pthreaded libstdc++, and both libgcc_s and
libgcc_s_pthread. This is definitely wrong.

What i found out:

*) works with libtool-1.5.10

*) libtool uses two different ways to ask gcc for the library pathes:

  1) sys_lib_search_path_spec=`$CC -print-search-dirs | grep ...`
   gcc does not print the pthread-subdir (for pthreaded-libstdc++)
   with -print-search-dirs, even if -pthread would be passed.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruno Haible | 12 Jan 2006 21:35

Re: new module 'ldd'

[redirected to bug-libtool, from bug-gnulib]
Ralf Wildenhues wrote:

> > The fact that a libtool created "program" is not actually a program but a
> > script, is a problem of libtool. Fix that, then we can also use
> > "gdb program" instead of the surprising syntax "libtool gdb program".
>
> Two comments: I have yet to see a proposal how uninstalled programs may
> load uninstalled libraries on all systems, without using a wrapper of
> some sort.

Here is a proposal that works on glibc systems and possibly other systems:
Create the uninstalled program in the current directory, with -rpath
linker options that refer to directories containing uninstalled libraries.

During installation "libtool --mode=install" will have to create a
different executable, with different -rpath options.

This works on glibc systems because the -rpath directories have
precedence over the LD_LIBRARY_PATH directories.

The most important Unix systems (Linux, Solaris, HP-UX, AIX, IRIX, OSF/1,
FreeBSD, OpenBSD, NetBSD) all support -rpath or equivalent for executables.
But on some the precedence is reversed, for example on IA64 HP-UX,
the LD_LIBRARY_PATH is consulted before the embedded rpath. On these
systems my proposal will not work.

> Note on some systems (GNU/Linux/GCC for example) there is
> a trade-off to make wrt. fast-install
(Continue reading)

Permalink | Reply | 4 comments |
headers
Aleksandar Milivojevic | 12 Jan 2006 16:49

libtool not hardlinking library path on sparc*-sun-solaris*

I've a problem with libtool (1.5.22 and the version included with gcc 
4.0.2).  Platform is sparc*-sun-solaris*.  Using gcc 4.0.2.  The linker 
doesn't seem to influence it (I've had same problem with gcc build that 
uses Sun ld and the build that uses Gnu ld).

When creating shared libraries, the library path is not hardcoded into 
executable.  On Solaris system, this may result in dynamic linker 
failing to load dynamic libraries during runtime.

Looking at generated libtool script, it should have been hardcoded 
(hardcode_into_libs is correctly set to yes).

For example, if linking shared library (linkmode=lib), this is what I get:

./libtool --mode=link gcc -o libfoo.la -rpath /prefix/lib list-of-files
gcc -shared list-of-files -lc -Wl,-soname -Wl,libfoo.so.0 -o 
.libs/libfoo.so.0.0.0

The resulting link command is missing "-Wl,--rpath -Wl,/prefix/lib" 
options (example using Gnu ld).  Same thing happens when using gcc 
configured to use Sun ld.  Since libfoo.so is generated using gcc, it 
depends on libgcc_s.so which is installed in /prefix/lib (alongside the 
remainder of gcc package).

On the other hand, when linking programs (linkmode=prog), everything 
works as expected:

./libtool --mode=link gcc -o foo foo.o -rpath /prefix/lib
gcc -o foo foo.o  -Wl,--rpath -Wl,/prefix/lib
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ralf Wildenhues | 12 Jan 2006 23:17
Picon
Picon

Re: libtool not hardlinking library path on sparc*-sun-solaris*

Hi Aleksandar,

* Aleksandar Milivojevic wrote on Thu, Jan 12, 2006 at 04:49:48PM CET:
> I've a problem with libtool (1.5.22 and the version included with gcc 
> 4.0.2).  Platform is sparc*-sun-solaris*.  Using gcc 4.0.2.  The linker 
> doesn't seem to influence it (I've had same problem with gcc build that 
> uses Sun ld and the build that uses Gnu ld).
> 
> When creating shared libraries, the library path is not hardcoded into 
> executable.  On Solaris system, this may result in dynamic linker 
> failing to load dynamic libraries during runtime.

> ./libtool --mode=link gcc -o libfoo.la -rpath /prefix/lib list-of-files
> gcc -shared list-of-files -lc -Wl,-soname -Wl,libfoo.so.0 -o 
> .libs/libfoo.so.0.0.0
> 
> The resulting link command is missing "-Wl,--rpath -Wl,/prefix/lib" 
> options (example using Gnu ld).

Please rerun above command with `./libtool --debug' and post the output,
packed (bzip2 or gzip preferred); also `./libtool --debug'.

Cheers,
Ralf
Permalink | Reply | 3 comments |
headers
Bob Friesenhahn | 12 Jan 2006 23:48
Picon
Picon
Gravatar

Re: new module 'ldd'

On Thu, 12 Jan 2006, Bruno Haible wrote:
>
>> Note on some systems (GNU/Linux/GCC for example) there is
>> a trade-off to make wrt. fast-install
>
> Being a developer, I'm asking to make the trade-offs in favour of the
> developer's comfort, i.e. optimized for "make", "gdb", and "make check",
> at the expense of a slower "make install" :-)

Your bias is obvious. :-)

>From the non-developer standpoint, the objective is to configure and 
install the package as quickly as possible and libtool has 
historically substantially slowed down this process.  Libtool 2.0 will 
be a big improvement in this regard.  Is it really worthwile to 
penalize the build/install times for many people for the convenience 
of the package developer?  On source-based systems like Gentoo, every 
bit of build efficiency counts.

>> So, no, I don't acknowledge that as bug, but as (necessary) limitation.
>
> glibc systems are the platforms on which most of us are developing. Isn't
> it worth to optimize libtool for these platforms?

Speak for yourself. :-)

Is there any significant use of glibc other than Linux?  If everyone 
was using Linux we would not need libtool at all!

Bob
(Continue reading)

Permalink | Reply | 0 comments |

Gmane