Re: [PATCH] GCC multilib vs. OS multilib naming (take 2)

[Alexandre Oliva <aoliva at redhat dot com>]

On Oct  4, 2002, Jakub Jelinek <jakub@redhat.com> wrote:

>> Should LIBRARY_PATH and LPATH really follow multilib_os?  I have mixed
>> feelings about it, and I'm more inclined to NOT enable it.

> I tried to follow the rule if the prefix ends with /lib, which I think
> both LIBRARY_PATH and LPATH usually does, then it should
> be OS, otherwise GCC.

This would require the linker to also apply the same transformations,
I think, because it's the linker that cares about LD_LIBRARY_PATH.

BTW, this brings me to the only think I slightly dislike about your
approach.  It assumes libdir is ...../lib, and it doesn't work
correctly if this assumption is broken.  I wonder if it's not too late
to rework it such that, instead of printing a relative pathname from
${libdir} into the multilib-specific dir, we wouldn't be better
printing a suffix to be appended to libdir.  I.e., instead of using
${libdir}/`gcc -print-multi-os-directory`, we'd use, for example,
`${libdir}`gcc -print-multi-os-libdir-suffix`

This option would print `64' if lib64 is sibling to lib, `/sparcv9' if
it's a subdirectory, etc.  The advantage is that if you change
--libdir to .../foo, you'd get say .../foo64 for the 64-bit libraries,
instead of .../foo/../lib64, that would probably be inappropriate.

Sorry for not bringing this up before, and apologies if it was
debated and beat before.

> Oops.  I need to fix --disable-multilib on 64-bit arches so I'll bootstrap
> and post it together.

Thanks.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer