[Top][All Lists]

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

Re: another 1.5 release

From: Bob Friesenhahn
Subject: Re: another 1.5 release
Date: Fri, 3 Dec 2004 13:03:22 -0600 (CST)

On Fri, 3 Dec 2004, Daniel Reed wrote:

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 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.

Libtool already caches compiler-specific information. For example, if one instance of GCC uses GNU ld while the other uses the vendor linker, libtool will have cached results based on the GCC it was configured with, and may mis-behave with a different GCC. It is also likey that GCC 2.X behaves a bit differently than GCC 3.X.

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

Profound changes like this should not be introduced in a bug-fix branch.

There is no doubt that the patch adds substantial value.

Bob Friesenhahn

reply via email to

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