On Aug 11, 2004, Daniel Reed [EMAIL PROTECTED] wrote:
On 2004-08-12T09:00+0900, Peter O'Gorman wrote:
) Daniel Reed wrote:
) On 2004-08-11T10:06+0900, Peter O'Gorman wrote:
) ) Daniel Reed wrote:
) ) libtool-1.4.2-multilib.patch
) )This patch is needed for multilib support. It has been sent upstream
) )but basically rejected in its current form as being too Red Hat specific.
) ) [Is this still the case? Is there an alternate solution for this problem, or
) ) is .multilib still the only one?]
) Thanks for the url. I have to agree with Scott, looks like adding this patch
) here would be a bad thing, it may break other linux distros. Someone,
) someday, will come up with a generic way of doing this that works on all
) flavours of GNU/linux. They don't seem to have done so yet.
Would it be reasonable to make this a ./configure option at libtool build
time?
God, no!
It means every package would have to use this option at configure
time, otherwise it wouldn't work.
I think the best we can do is to run something like:
case `$CC $CFLAGS -print-file-name=libc.so || gcc -print-file-name=libc.a` in
# common case, good
*/lib/libc.so | */lib/libc.a) libsuff= ;;
# many 64/32 arches use lib for 32-bit libs and lib64 for 64-bit libs
*/lib64/libc.so | */lib64/libc.a) libsuff=64 ;;
# mips64-linux uses lib32 for N32
*/lib32/libc.so | */lib32/libc.a) libsuff=32 ;;
# Shouldn't happen... What now?
*) libsuff= ;;
esac
This should probably be amended to match Debian GNU/Linux x86_64
practice.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
