libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: another 1.5 release


From: Daniel Reed
Subject: Re: another 1.5 release
Date: Fri, 3 Dec 2004 13:55:09 -0500 (EST)

On 2004-12-03T11:48-0600, Bob Friesenhahn wrote:
) On Fri, 3 Dec 2004, Albert Chin wrote:
) > Shouldn't we come up with a more general solution first? Embedding
) > knowledge of a specific compiler in ltmain.sh is wrong. That's what
) > libtool.m4 is for.

The GCC-specific code operates (and must operate) per libtool invocation,
not at configure time. GCC is used to find the files if a) GCC is in use (as
determined by configure) and b) the GCC in use supports -print-file-name (as
determined per libtool invocation). It might make sense to move the check to
see if GCC supports -print-file-name into configure, but that would be an
optimization rather than a user-visible behavior change.


) > Is there general consensus of this patch as a model for other
) > platforms (Solaris, Linux with non-GCC compilers, IRIX, etc.)? It
) > seems way too Linux-specific to me.

The patch is specific to GCC, not Linux. Any operating system that uses a
multilib-capable GCC should be supported by the code introduced in this
patch.


) that only bug-fixes should appear in branch-1-5 and this smells like a
) new feature to me.  Since branch-2-0 has not yet produced a release,

The patch is to solve the following problem:

address@hidden:~/libtool-1.5.10_orig-build$ ./libtool --mode=link gcc -m64 
-shared -o library.so -lpopt
gcc -m64 -shared -o library.so  /usr/lib/libpopt.so
/usr/lib/libpopt.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
address@hidden:~/libtool-1.5.10_orig-build$

Like this:

address@hidden:~/libtool-1.5.10-build$ ./libtool --mode=link gcc -m64 -shared 
-o library.so -lpopt
gcc -m64 -shared -o library.so  /usr/lib64/libpopt.so -Wl,--rpath 
-Wl,/usr/lib64 -Wl,--rpath -Wl,/usr/lib64
address@hidden:~/libtool-1.5.10-build$


Software packaged with a stock Libtool must be relibtoolized before it can
be built in a multilib (64-bit and 32-bit compat) environment. Red Hat has
been shipping a Libtool package with a Linux-specific patch since multilib
became a supported target; I would like to see a more generic fix introduced
upstream so Red Hat will not have to continue patching Libtool.

-- 
Daniel Reed <address@hidden>    http://people.redhat.com/djr/   
http://naim.n.ml.org/
"Murphy's Law is recursive. Washing your car to make it rain doesn't
work."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]