Re: another 1.5 release?

[Ralf Wildenhues]

* Daniel Reed wrote on Sat, Jan 29, 2005 at 07:31:41PM CET:
> On 2005-01-28T22:03+0100, Ralf Wildenhues wrote:
> ) This is a misunderstanding.  Think libstdc++.la in a custom gcc
> ) installation, say, in $HOME/local.
> )
> ) If your patch was applied, the following happens:
> ) Libtool finds it in the search paths that are checked _before_
> )   gcc -print-file-name
> ) will even be tried for finding it.
> )
> ) For one of -m32/-m64, things will break.
> )
> ) I have such a setup at work, BTW.
> 
> I am not convinced this isn't a broken setup, though.

Yes, after retrying what I tried to do back then, I think you are right
on this one.

> If your system is multiarch, extra care must be taken not to upset things.
> If your custom gcc finds a libstdc++.so in a location you specify with -L,
> it will find that libstdc++.so even if it "knows" better (and would have
> checked the lib64 equivalent instead without the -L option).
> 
> If you have a 32-bit library in your library search path while compiling
> 64-bit programs, or vice versa, things will blow up. This is true with or
> without the behavior of the multilib2 patch; multilib2 at most should just
> make the explosion more spectacular.

Yep.  Well, still what Libtool does (barf) is not the same as what ld
does (namely, skip the incompatible libraries and continue searching.
This alone might and will annoy users, but the behavior is arguable.

> Since the autotools collectively have not decided on a type of multilib to
> support out of the box, it becomes entirely the software builder's
> responsibility to ensure no 32-bit/64-bit mixups occur. For example, Red Hat
> may make sure programs built for 64-bit targets have a libdir set to
> /usr/lib64, with programs built for 32-bit targets (on 64-bit machines)
> still having a libdir of /usr/lib. Red Hat could then make sure gcc,
> binutils, etc. all knew of this convention, and could find the appropriate
> versions of libraries without resorting to checking all /usr/lib* locations
> and checking for which name matches were also arch matches. Site-specific
> software builders have to do the same.
> 
> So no custom gcc/binutils, and no temporary -L path, should ever point gcc
> to a directory holding 32-bit libraries when the target is 64-bit, and vice
> versa. If you have libstdc++.so outside of gcc's normal search path, make
> sure you specify gcc -L/usr/local/lib64 and not /usr/local/lib.
> Consequently, make sure you install the custom libstdc++ with libdir set to
> /usr/local/lib64 and not /usr/local/lib. I am not sure Libtool should try to
> do anything special if you do not do this; if anything, it should explode as
> spectacularly as possible to help identify the situation as a problem
> situation, so it can be fixed as early as possible.

Yes.  The fact that multilib solutions are all different and maybe
incompatible is unfortunate.  But we cannot change this now.

> ) So now we know why FC ships only one ABI version of these -devel packages :)
> 
> address@hidden ~ =) # rpm -qf /usr/lib/libbind9.so /usr/lib/libbind9.la 
> /usr/lib64/libbind9.so /usr/lib64/libbind9.la
> bind-libs-9.3.0-2.i386
> bind-libs-9.3.0-2.i386
> bind-libs-9.3.0-2.x86_64
> bind-libs-9.3.0-2.x86_64
> address@hidden ~ =) # rpm -qf /usr/lib/libGL.so /usr/lib64/libGL.so
> xorg-x11-devel-6.8.1.902-4.i386
> xorg-x11-devel-6.8.1.902-4.x86_64
> 
> gcc knows which set to use, and will use the correct one unless you force it
> otherwise with a spurious -L option.

Yeah, I should have written:

> ) So now we know why FC ships only one ABI version of these -devel packages :)
                                                       *these*

I know it does ship both devel versions of many packages, and I am
impressed by how well they did get most of this working.

> ) No, to be serious:  What can we do to solve this?
> 
> Put your faith in the system's build tool chain. If it doesn't know how to
> find libraries, all hope is already lost. We can't possibly do a better job
> using uninformed magic.

Let's see.

Thanks for your comments on all this,
Ralf