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
