On Thu, 2004-08-12 at 18:12, Peter O'Gorman wrote: > Bob Friesenhahn wrote: > > > On Thu, 12 Aug 2004, Tim Mooney wrote: > > > >> Why just Linux? Isn't this essentially the same issue that the multi-ABI > >> commercial UNIXes have? > > > > > > Seems like it to me. I am not sure. Solaris-gcc applies traditional multilibs, i.e. it is using multilib subdirs (A subdir of PREFIX/lib).
I don't know how "multiarchs" are implemented in RH's ix86_64 gcc. /usr/lib64 is not a subdir of PREFIX/lib > For example, Solaris puts 64-bit libraries in a > > 'sparcv9' subdirectory. The 'sparcv7' directory is used for libraries > > built for older SPARC processor types. Libraries optimized for 32-bit > > Ultrasparc are put in the traditional location. > > Well, the difference, in my little mind at least, is that the commercial > unixes can all be identified in libtool using $host, Right, you can identify $host and in case of Solaris even the OS version as part of $host (solaris2.8). However, you can not identify the multilib-variant and the multilib subdir being used from $host, because it is chosen depending upon the flags being passed to gcc: sparc-sun-solaris2.8-gcc .. -> . (sparcv7) sparc-sun-solaris2.8-gcc -m64 .. -> sparcv9 => There is no fixed "host" to multilib subdir mapping. IMO, RH's multilib-patch is just a "band-aid" (read: hack) to help them keep libtool going on their systems, but is not a generalizable approach. How do other Linux vendors (Debian, SuSE etc.) handle this issue? I would expect them to be facing the same problems as RH and to have similar work-arounds applied to libtool. Ralf _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
