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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
