libtool 1.4.3 searches /usr/lib before -Ldir
I've asked for help about this problem twice in the last few weeks, without any replies. In the meantime I've done some searching in the libtool list history, and I came across this: http://www.mail-archive.com/[EMAIL PROTECTED]/msg04324.html This seems to be exactly the same problem I'm having. Now I'm wondering, has the reason, and possibly a solution for this problem been found in the meantime? Regards, Pieter ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4.3 searches /usr/lib before -Ldir
In regard to: libtool 1.4.3 searches /usr/lib before -Ldir, Pieter...: I've asked for help about this problem twice in the last few weeks, without any replies. I saw your posts, but don't recall whether this is something you've tried with libtool 1.5.2 or not. Have you? The libtool developers have expressed extreme reluctance to spend much time on code that is an evolutionary dead end. All new work is going into the 1.5.x and later lines of development. In the meantime I've done some searching in the libtool list history, and I came across this: http://www.mail-archive.com/[EMAIL PROTECTED]/msg04324.html If you download libtool 1.4.3 and look at ltmain.in, you'll see about a dozen places where newlib_search_path is set to something. In each case, the assignment ends up looking like newlib_search_path=$newlib_search_path something else here If you try systematically changing these to newlib_search_path=something else here $newlib_search_path you should eventually be able to arrive at the combination of settings that are causing the problem for you. My *guess* (and that's all it is) is that it's either the place where it's under a case for `-L', or it's the place where you have newlib_search_path=$newlib_search_path $ladir Do some testing, and report back what you find. Better yet, test with libtool 1.5.2. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
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
Re: libtool 1.4.3 searches /usr/lib before -Ldir
On Mon, Oct 20, 2003 at 07:32:21PM -0400, Pierre Sarrazin wrote: 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. You should use libtool 1.5 if you're using C++. 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 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. -- albert chin ([EMAIL PROTECTED]) ___ 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
