Re: another 1.5 release?

[Daniel Reed]

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.

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.

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.



) > ) Using stuff like pkg-config breaks very nicely if they add both
) > )   -L/foo/lib  and -L/foo/lib64
) > ) to the command line (because we search that before -print-file-name as
) > ) well).  I do not know the extent of such possible breakage.
) >
) > We already lose in that situation:
) >
) > address@hidden ~ =) # gcc -shared -o test -lsnmp
) > address@hidden ~ =) # gcc -shared -o test -L/usr/lib -lsnmp
) > /usr/bin/ld: skipping incompatible /usr/lib/libsnmp.a when searching for 
-lsnmp
) > /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
) > /usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc
) > address@hidden ~ =) #
)
) 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.


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

-- 
Daniel Reed <address@hidden>    http://people.redhat.com/djr/   
http://naim.n.ml.org/
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man. -- George Bernard Shaw