GNU bug report logs - #38610
Two libtool 2.4.6 issues

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38610 in the body.
You can then email your comments to 38610 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sergey Poznyakoff <gray <at> gnu.org>
To: <bug-libtool <at> gnu.org>
Subject: Two libtool 2.4.6 issues
Date: Sat, 14 Dec 2019 13:23:33 +0200

Dear maintainers,

When working on GNU mailutils we have discovered two issues with libtool,
which probably qualify as bugs.

Issue 1:

Imagine a project consisting of at least one installable shared
library (libltb1) and an installable binary program (ltb1), which is
linked with that library. If the ltb1_LDFLAGS variable contains one
or more -Wl,-rpath linker options, the created wrapper script will
prefer directories listed in them over locations in the build tree. If
a previous version of the libltb1 library is already installed in one
of these directories, the ltb1 wrapper will use the installed version
of the library, instead of the one from the source tree. This leads to
undesirable consequences, e.g. if the package provides a test suite,
it will likely fail, since it will be using wrong library version.

This issue is described in detail here:

  http://gray.gnu.org.ua/public/ltbug/#ltb1

The test case is available for download from:

  http://gray.gnu.org.ua/public/ltbug/ltbug-1.tar.gz

(to test, unpack the archive and run 'sh ltbug-1/test.sh')
  
The proposed patch is available from:

  http://gray.gnu.org.ua/public/ltbug/0001-ltmain.in-append-rpath-option-arguments-to-finalize_.patch

Issue 2:

Imagine a project consisting of two installable libraries (liba, and
libb) and a binary (ltb2) linked to both of them. Let liba depend on an
external library, which has a libtool archive installed along with the
shared library.  This archive obviously contains the libdir variable
pointing to its installation directory (let's name it D).  Then, the
wrapper script for ltb2 is created in such a way, that liba is searched
in the source tree, but the libb is searched first in D and then in the
source tree. If a prior version of the project is installed in the same
prefix as the libdep library, then the ltb2 wrapper will use the version
of liba from the local source tree, but the version of libb installed on
the system.

This issue is described in detail in:

  http://gray.gnu.org.ua/public/ltbug/#ltb2

The test case is available for download from:

  http://gray.gnu.org.ua/public/ltbug/ltbug-2.tar.gz

(to test, unpack the archive and run 'sh ltbug-2/test.sh')  
  
The proposed patch is available here:

  http://gray.gnu.org.ua/public/ltbug/0002-ltmain.in-ensure-that-local-source-tree-directories-.patch

Both issues were confirmed to exist on GNU/Linux and on FreeBSD.  See
http://gray.gnu.org.ua/public/ltbug#affected-systems for a complete list
list.  Both libtool 2.4.6 and the development version from git HEAD
were tested.

Best regards,
Sergey

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Roumen Petrov <bugtrack <at> roumenpetrov.info>
To: 38610 <at> debbugs.gnu.org, Igor Rondarev via Bug-libtool <bug-libtool <at> gnu.org>
Cc: Sergey Poznyakoff <gray <at> gnu.org>
Subject: Re: bug#38610: Two libtool 2.4.6 issues
Date: Sun, 15 Dec 2019 12:03:45 +0200

Hello,

Sergey Poznyakoff wrote:
> Dear maintainers,
>
> When working on GNU mailutils we have discovered two issues with libtool,
> which probably qualify as bugs.
> [SNIP]

Build with installed library into non-default locations most of the time 
is painful.

In one of models each library set(package) is installed in separate 
directory in format like this: <install>/<package>-<version>.
This model prevents load of headers and library from unexpected location 
but build use many -I and -L flags. Let skip -R/-rpath flags for simplify.

Another model is installation in common path. In this case flags are 
less but build is more tricky - user must ensure precedence of headers 
(-I) and libraries (-L) from source tree.

So report is for libtool and samples are for libraries but case is 
applicable for header files as well. And for headers we cannot blame 
libtool.

Tips:
I prefer first model but in one case I use second.
Let headers are in <INSTALL>/include and libraries are in <INSTALL>/lib
In the second with limited number of projects:
- if build uses shell script to return path to headers and libraries 
script must be modified do not output -I and -L flags.
- if build uses pkgconfig environment must be set so that command do not 
output -I and -L flags.
- libtool is tuned with new "system library path" : variable 
lt_cv_sys_lib_dlsearch_path_spec, work fine on unixes.
- CC is overridden to use flags like --sysroot, -isystem, -B and etc. 
Unfortunately clang lack flag to add item to "system library search 
path" and so gcc is preferred.


Remark:
In one of the provided samples is hard coded path -L $(libdir), i.e. 
-L<path> -l<lib> This should be $(FOO_LIBS) and depending from model at 
configuration time is should be set either to -L<path> -l<lib> or only 
to -l<lib>. First is usable for model with separate directories 
otherwise should be used second one.


Regards,
Roumen Petrov

P.S. samples:
$ pkg-config --libs openssl
-lssl -lcrypto
$ PKG_CONFIG_SYSTEM_LIBRARY_PATH=/bon/go pkg-config --libs openssl
-L/usr/lib64 -lssl -lcrypto

So with PKG_CONFIG_* environment variables build could be tuned to 
exclude -I and -L flags.
Note pkg-config flags lib-only* and cflags-only* are out of scope.

Message #14 received at 38610 <at> debbugs.gnu.org (full text, mbox):

From: Sergey Poznyakoff <gray <at> gnu.org.ua>
To: "Roumen Petrov" <bugtrack <at> roumenpetrov.info>
Cc: 38610 <at> debbugs.gnu.org, Igor Rondarev via Bug-libtool <bug-libtool <at> gnu.org>
Subject: Re: bug#38610: Two libtool 2.4.6 issues
Date: Sun, 15 Dec 2019 20:11:47 +0200

Hi Roumen,

Roumen Petrov <bugtrack <at> roumenpetrov.info> ha escrit:

> Build with installed library into non-default locations

There's no question about non-default locations.  In real life examples,
all locations are system defaults.

> most of the time is painful.

And one of the purposes of libtool is to make it less painful.  That's
why I took the trouble to write a report.

> So report is for libtool and samples are for libraries but case is
> applicable for header files as well.

Header files are completely irrelevant here.  Both issues clearly
demonstrate that the problem is related to shared objects only,
explain why, and propose the ways to fix.

> Remark:
> In one of the provided samples is hard coded path -L $(libdir),
> i.e. -L<path> -l<lib>

Yes, and a rationale for it is provided.

> This should be $(FOO_LIBS) and depending from

This would imply parsing the output from krb5-config and splitting it
into _LIBS and _LDFLAGS related parts.  That was attempted as well, but
did not alleviate the problem in any way.

> $ pkg-config --libs openssl

Thanks, but pkg-config is not used at all.

Regards,
Sergey

Message #22 received at 38610-done <at> debbugs.gnu.org (full text, mbox):

From: Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>
To: 38610-done <at> debbugs.gnu.org
Cc: Sergey Poznyakoff <gray <at> gnu.org>
Subject: bug#38610: Two libtool 2.4.6 issues
Date: Wed, 25 Sep 2024 21:07:47 +0300

[Message part 1 (text/plain, inline)]

Closing duplicate of 71489 [1].

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71489

-- 
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354

[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]

[OpenPGP_signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.