Re: libtool 1.4.3 searches /usr/lib before -Ldir
Dixit Albert Chin (2003-10-21 10:47): The -L option correctly points to the src/verbiste directory, where the newer library has been compiled. However, libtool generates this g++ command to do the linking: g++ -g -Wall -o french-conjugator french_conjugator-french-conjugator.o french_conjugator-Command.o /usr/lib/libxml2.so -lpthread -lz -lm -L/home/ps/cvswork/verbiste/src/verbiste /usr/lib/libverbiste-0.1.so Does this patch (against 1.5) work for you? http://mail.gnu.org/archive/html/libtool/2003-10/msg00067.html It should be trivial to apply the patch to your 1.4.3 version. I've tried libtool 1.5 both with and without this patch, and the problem remains the same. But instead of searching /usr/lib explicitly, it searches /usr/lib/gcc-lib/i386-redhat-linux/3.2/../../.. instead, which is equivalent... I've attached a patch (against 1.5) that works for me. At the following point in ltmain.in, I changed the order of the stuff that gets assigned to newlib_search_path. The new directory is now prepended instead of being appended: prog) if test $pass = conv; then deplibs=$deplib $deplibs continue fi if test $pass = scan; then deplibs=$deplib $deplibs newlib_search_path=`$echo X$deplib | $Xsed -e 's/^-L//'` $newlib_search_path else compile_deplibs=$deplib $compile_deplibs finalize_deplibs=$deplib $finalize_deplibs fi ;; This puts the right directory before /usr/lib instead of after. (I notice that this code segment is the only one in the script that compares $pass with 'scan'.) I don't know if this patch would be appropriate for all users of libtool however... -- Pierre Sarrazin sarrazip at sympatico . ca --- ltmain.in.orig 2003-10-22 01:57:53.0 -0400 +++ ltmain.in 2003-10-22 02:24:08.0 -0400 @@ -1883,7 +1883,7 @@ fi if test $pass = scan; then deplibs=$deplib $deplibs - newlib_search_path=$newlib_search_path `$echo X$deplib | $Xsed -e 's/^-L//'` + newlib_search_path=`$echo X$deplib | $Xsed -e 's/^-L//'` $newlib_search_path else compile_deplibs=$deplib $compile_deplibs finalize_deplibs=$deplib $finalize_deplibs ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool 1.4.3 searches /usr/lib before -Ldir
I'm having a problem related to the path that libtool (1.4.3)
uses to search for libraries.
I have a C++ package that contains a library and two command-line
tools. If I install this package through an RPM (on a RedHat 8.0
system), I endup with the lib*.la and lib*.so files in /usr/lib.
I get into trouble when I compile the sources of a newer version
of the package, while the older version is still installed.
For example, I deploy the newer version in /home/ps/cvswork/verbiste.
The library sources are in src/verbiste, and its .libs subdirectory.
The command-line tool sources are in src/commands. The library is
compiled first, then the command-line tools. The error happens when
trying to link the first of those tools.
The libtool command that is run by make is the following:
/bin/sh ../../libtool --mode=link g++ -g -Wall
-o french-conjugator
french_conjugator-french-conjugator.o french_conjugator-Command.o
-lxml2 -lpthread -lz -lm
-L../verbiste -lverbiste-0.1
The -L option correctly points to the src/verbiste directory, where the
newer library has been compiled. However, libtool generates this g++
command to do the linking:
g++ -g -Wall -o french-conjugator
french_conjugator-french-conjugator.o french_conjugator-Command.o
/usr/lib/libxml2.so -lpthread -lz -lm
-L/home/ps/cvswork/verbiste/src/verbiste
/usr/lib/libverbiste-0.1.so
The `-lverbiste-0.1' has been expanded to `/usr/lib/libverbiste-0.1.so'
because the older version of the library is currently installed as an
RPM under /usr. This causes a linking error because the older library
does not have the functions that are expected by the newer code:
/home/ps/cvswork/verbiste/src/commands/french-conjugator.cpp:110:
undefined reference to
`verbiste::FrenchVerbDictionary::getTenseName(verbiste::Tense)'
I wondered why libtool searched a system directory (/usr/lib) before
the explicitly specified one (../verbiste). I opened ../../libtool
and found this (backslash added by me):
for searchdir in $newlib_search_path $lib_search_path \
$sys_lib_search_path $shlib_search_path; do
# Search the libtool library
lib=$searchdir/lib${name}.la
if test -f $lib; then
found=yes
break
fi
done
By inserting echo statements before this loop, I observed this (long
line cut by me):
newlib_search_path=' /usr/lib /home/ps/cvswork/verbiste/src/verbiste'
lib_search_path='/home/ps/cvswork/verbiste/src/commands
/home/ps/cvswork/verbiste/src/verbiste'
The directory specified with -L was added after /usr/lib.
This explains why libverbiste-0.1.la is found in /usr/lib instead
of where -L specified.
The workaround is to uninstall the older library, or at least to
move away /usr/lib/libverbiste-0.1.la.
Is there a clean way to ask libtool to search a certain directory
before any system directory?
My project is autoconfiscated with autoconf 2.57, automake 1.7.2
and libtool 1.4.3. Also, I use g++ 3.2 on a RedHat 8.0 system.
--
Pierre Sarrazin sarrazip at sympatico dot ca
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Enabling/disabling shared or static libs from Makefile.am
I am autoconfiscating a large source tree with Autoconf (2.13), Automake (1.4) and Libtool (1.3.5) on a GNU/Linux system. In this tree, there are subtrees that constitute the sources for shared libraries. Other subtrees should give static libraries because they will never be needed in shared form. Yet other subtrees define executable commands. In the Makefile.am files that define the libraries, I specify that I want to build libtool libraries, e.g., libfoo.la. One problem is that libtool then compiles every source file twice: once with position-independent code for a shared library, and once with position-dependent code for a static library. None of the libraries need to be created in both shared and static form. Thus, compiling twice wastes time and disk space. I know that I can specify AC_DISABLE_STATIC before AM_PROG_LIBTOOL in the configure.in file. But then, all libraries are created in shared form, which is inappropriate in my case. This solution is too centralized. Logically, it is in a Makefile.am file that I would like to ask that a specific library should be static. There is one Makefile.am file in which I build two libraries: lib_LTLIBRARIES = libutils.la libmem.la libutils should be static, while libmem should be shared. I tried adding the -static flag to the *_LDFLAGS variable: libutils_la_LDFLAGS = -version-info 0:0:0 -no-undefined -static But the source files are still compiled twice. Does automake support what I am trying to say? I would not mind if all source files were compiled as position-independent code, even for static libraries. -- Pierre Sarrazin sarrazip -at- sympatico -dot- ca ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
