I've just built gcc with sparc64 as build target (64-bit gcc binary that generates 64-bit code by default, much like Linux amd64 does).
I've noticed one inconsistency how libraries are installed. For shared libraries (lib*.so), the 32-bit version is installed in prefix/lib, while 64-bit version is installed in prefix/lib/sparcv9. For static libraries (lib*.a archives), it is the other way around. The 64-bit version is installed in prefix/lib, while 32-bit version is installed in prefix/lib/sparcv7!? Just wondering if this was by design, and/or if there was some good reason for this? Looking at the system libraries (/lib, /usr/lib), the lib/lib*.a are 32-bit, there is no sparcv7 directory anywhere in sight. There's almost no static 64-bit libs either (with exception of two, libadt_jni.a and libldfeature.a, and they are in lib/sparcv9 as expected). A bit off topic. While configure script for gcc creates makefiles that generate both 32-bit and 64-bit libraries, I noticed that configure script in all other GNU packages doesn't. Even more, when building on sparc64 target, the libraries (which are 64-bit) get installed in prefix/lib (not in prefix/lib/sparcv9). Hmmm... kind of annoying. Is this generic configure script problem, or libtool problem, or developers not caring about Solaris 32/64 bit specifics, or something else? Any good way to go around that? I've used --libdir $prefix/lib/sparcv9, but that has side effect of placing data files in sparcv9 with some packages (while only 64-bit libs should go there). Gettext is an example of such package where using --libdir has not desired side-effects. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
