Re: Libtool attempts to link 64-bit lib on a -m32 compile (using Pathscale C++)

[Coleman Kane]

On Thu, 2009-03-12 at 19:54 +0100, Ralf Wildenhues wrote:
> Hello Coleman,
> 
> * Coleman Kane wrote on Thu, Mar 12, 2009 at 07:22:31PM CET:
> > 
> > Libtool doesn't perform much low-level investigation of the library file
> > types, nor does it rewrite paths to accommodate the 20-million different
> > ways that vendors install 32/64-bit libraries on the same system. 
> 
> True.
> 
> > Additionally, there may be legitimate cases where you actually want to
> > link 32 and 64-bit objects together.
> 
> Not very many though.  The most common exception are systems which
> bundle ABIs in one library.

Such are what I was considering. It looks like his link line, however,
is bringing in all of the code for the 64-bit runtime (crt*.o etc...).

> 
> > Specifically, you are linking in "/usr/lib64/libstdc++.so" by absolute
> > file name, which is considered to be in the categories of "user error".
> 
> Careful here.  That was output by libtool.  Absolute file name linking
> is problematic on some BSD systems, but normally not on GNU/Linux, at
> least not for libstdc++ which has a DT_SONAME set.  So if libtool
> creates absolute links on FreeBSD which cause DT_NEEDED entries with
> directory components in the output, then please report this.  Thanks.

If libtool is adding the library (/usr/lib64/libstdc++) itself, then
that sounds like it could be a bug. I have only ever experienced this
when either a pkgconfig file (lib/pkgconfig/*.pc or
libdata/pkgconfig/*.pc) has "/usr/lib64/libstdc++.so" or when a *.la
library linker script file (lib/*.la) has "/usr/lib64/libstdc++.so" in
it, typically when doing my own development. This seems extremely
prevalent when I am building my own compiler+binutils and using that for
cross-platform development, and never when I'm using the native compiler
set for my OS.

It is important to figure out where those stdlib arguments are coming
from.

I may have seemed to jump to conclusions in my earlier email. This could
end up being a bug in libtool. However, I've run into similar situations
many times before, and all of them have been the result of another
package adding an undesirable lib path or lib expansion into the command
line. For example, the sdl.m4 shipped with libSDL causes this many
times, by forcing a search of /usr/local/lib and /usr/lib in AM_PATH_SDL
for some reason (it may be fixed now). So my earlier e-mail should be
interpreted as "the most likely cause, from my experience".

Another situation that I didn't consider might be where you have ended
up using your system's "g++" (the default) as the compiler, and pathCC
as the linker for some reason. A quick inspection of config.log would
reveal this.

> 
> Cheers,
> Ralf
> 

-- 
Coleman Kane