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 10:54:49 -0500 (EST)

On 2004-12-03T11:08+0100, Ralf Wildenhues wrote:
) * Scott James Remnant wrote on Fri, Dec 03, 2004 at 10:06:01AM CET:
) > On Thu, 2004-12-02 at 18:36 -0500, Daniel Reed wrote:
) > > Is there any chance .multilib2 can be incorporated into 1.5.12? As 
written,
) > > it simply causes libtool to ask gcc to find .la files if gcc is in use. It
) > > should have no impact on non-gcc builds and should not cause any files to 
be
) > > missed (the original behavior is used if gcc is unable to find a requested
) > > file).
) > Do you have a copy of the patch to be considered?
) http://lists.gnu.org/archive/html/libtool-patches/2004-11/msg00123.html

Yep, that is still the latest version.

Instead of munging sys_lib_search_path_spec, this new patch causes Libtool
to use gcc's -print-file-name feature if present. This has an added benefit
of theoretically supporting multilib on non-Linux, gcc-using systems. It may
also more-closely fit Libtool's .la search algorithm with what GCC uses.

With the patch, Libtool will continue to honor -L paths first, then attempt
to use gcc -print-file-name, then fall back on $sys_lib_search_path and
$shlib_search_path. It should fail to use gcc -print-file-name gracefully if
either gcc is not in use or the gcc in use does not support
-print-file-name.

-- 
Daniel Reed <address@hidden>    http://people.redhat.com/djr/   
http://naim.n.ml.org/
The open source world considers many of its large projects as benevolent
dictatorships. It's a democracy only in the sense that cyberspace is
infinite so anyone who doesn't like it can move out. -- Alan Cox




reply via email to

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