Re: another 1.5 release?

[Daniel Reed]

On 2005-01-29T13:00-0600, Bob Friesenhahn wrote:
) On Sat, 29 Jan 2005, Daniel Reed wrote:
) > 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.
)
) This may be true for Linux but I believe that the Solaris linker
) ignores libraries which don't match the requested ABI.  Since libtool
) itself does not yet know about multilib ABIs, it is likely to choose
) the first matching library it finds, which may be the wrong ABI.

Since you can not generally specify -lfoo and have it find differently-named
files for different targets, my contention is that the files should already
be separated. You can not have a 32-bit libfoo.so and a 64-bit libfoo.so in
the same directory, so if you have both files, you would have different
directories to look in to find the correct libfoo.

Having one directory with a 32-bit libfoo and a 64-bit libbar does not make
sense if you have a 64-bit libfoo elsewhere or a 32-bit libbar elsewhere.
Put the 64-bit libfoo and libbar together, or put the 32-bit libfoo and
libbar together, or separate all four.

Therefore, if you are relying on the build tool chain's default path
searching to find -lfoo and you specify -L/usr/lib to find -lbar, it
*should* *not* find a libfoo of the wrong type in that directory. If it
does, either your libbar or this wrong-typed libfoo has been placed in the
wrong location.

The whole point behind multilib is to separate differently-typed libraries
from each other, to prevent these types of situations from occuring. If you
want to ignore whatever multilib method your base OS uses, just make sure
you don't install differently-typed libraries at the same time. (So a 32-bit
libfoo in /usr/lib next to a 64-bit libbar in /usr/lib is fine as long as
there are no other libfoos or libbars anywhere else, and nothing you
build/run expects there to be another libfoo or libbar elsewhere.)

The spectacular explosion from a multilib2ed Libtool would just serve as
stronger incentive to fix the type mixing that gcc itself does already warn
about (even if it continues operating in a less-predictable way).

-- 
Daniel Reed <address@hidden>    http://people.redhat.com/djr/   
http://naim.n.ml.org/
There are people who do things and people who take the credit, and the
trick is to be in the first group; there is a lot less competition. --
Dwight Morrow, American Diplomat