On 02/17/2010 01:39 PM, Dr. David Kirkby wrote:
Ben Taylor wrote:
On Thu, Feb 11, 2010 at 11:00 AM, Konstantin Andreev
<andreev@xxxxxxxxx> wrote:
In Solaris, libraries live in
32-bit : /usr/lib
64-bit : /usr/lib/64
where 64 -> amd64 or sparcv9
There's also /lib/amd64 and /lib/sparcv9. /usr/lib and /lib are *not*
linked.
I've noticed that some software installs files in places
/usr/local/amd64 or /usr/local/sparcv9, but does not create the link to
the "64" directory.
It is a bit of a mess.
I can only reiterate what I previously wrote: There are hundreds of such
multilib subdirs. Their names can be arbitrarily choosen by OS vendors.
Extreme cases can be found in embedded systems, which often provide
highly-optimized multilibs for many cpu-variant.
=> Any such heuritics is inevitably broken.
It's only that these heuristic's implementors likely haven't tripped
over these "less common" cases and believe the few they have encountered
are the only ones:
Just to provide further examples:
* sun-sparc-solaris2.7 (Antique/discontinued, > 10 years old):
lib
lib/sparcv9
* sparc for RTEMS (an embedded OS):
lib
lib/soft
lib/v8
lib/soft/v8
* powerpc for RTEMS (an embedded OS):
lib
lib/m403
lib/m505
lib/m601
lib/m603e
lib/m604
lib/m860
lib/m7400
lib/m8540
lib/nof
lib/m601/nof
lib/m603e/mpc8260
lib/m603e/nof
lib/m603e/mpc8260/nof
lib/m604/nof
lib/m7400/nof
lib/m8540/nof
For comparison: Red Hat x86_64-gcc
lib
lib64
Ralf
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
