[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#38610: Two libtool 2.4.6 issues
From: |
Roumen Petrov |
Subject: |
bug#38610: Two libtool 2.4.6 issues |
Date: |
Sun, 15 Dec 2019 12:03:45 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.5 |
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.