[Bug other/16513] New: Libiberty doesn't follow the multi-os-directory settings

["ebotcazou at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

This is a problem I've seen for ages (it affects 3.3.x, 3.4.x and mainline at
least) and I finally got around to wording it in technical terms.

On Solaris/SPARC, the 64-bit libraries are always installed in the sparcv9
subdirectory of the regular 'lib' directory, for example /usr/lib and
/usr/lib/sparcv9.

Therefore GCC must follow this rule for the libraries it installs.  This works
well for a multilib sparc-sun-solaris2.* compiler: the 64-bit libraries (either
static or dynamic) are installed in $(prefix)/lib/sparcv9.  This almost works
for a (multilib or not) sparc64-sun-solaris2.* compiler: the 64-bit libraries
are almost all installed in $(prefix)/lib/sparcv9, $(prefix)/lib containing
either nothing (non-multilib) or the 32-bit libraries (multilib).

The only exception is libiberty.a: for a sparc64-sun-solaris2.* compiler, the
64-bit version is installed in $(prefix)/lib (and a 32-bit version is installed
in $(prefix)/lib/sparcv7 in the multilib case), overriding a possible previous
32-bit libiberty.a installed by the sparc-sun-solaris2.* compiler.

The problem is that Libiberty's Makefile doesn't take into account the result of
$(CC) -print-multi-os-directory for a native compiler (it apparently does for a
cross-compiler), whereas all other libraries shipped with GCC do.

-- 
           Summary: Libiberty doesn't follow the multi-os-directory settings
           Product: gcc
           Version: 3.3.5
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: other
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ebotcazou at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: sparc64-sun-solaris2.*
  GCC host triplet: sparc64-sun-solaris2.*
GCC target triplet: sparc64-sun-solaris2.*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16513