Re: another 1.5 release

[Bob Friesenhahn]

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

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

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

There is no doubt that the patch adds substantial value.

Bob
======================================
Bob Friesenhahn
address@hidden
http://www.simplesystems.org/users/bfriesen