Daniel Reed 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?
Something like --enable-redhat-multilib or --with-multilib-flavor=RedHat ?
Or even something like --with-multilibformat='lib64' versus --with-multilibformat='$host_os/lib' ?
Well, lets think a bit. We want to add the 64bit specific directories for linux. Different linux distro's seem to be going with different places to put their 64 bit libs? Do all of them stay consistent?
e.g.
RedHat is
/lib64 /usr/lib64
etc...
Debian is
usr/x86_64-linux/lib
? and so on.
etc. etc.
What else is there? Did everyone chose a different system? That'd totally suck :(
I know bugger all about this, but I assume that there is a libc in one of these directories on all linux flavours? Can we test for libc.so in various dirs and then work out the proper sys_lib_search_path_spec etc?
Peter -- Peter O'Gorman - http://www.pogma.com
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
