On Thu, 8 Jan 2015, Steve Ellcey wrote:
> So I set these macros and SPECs:
> # m32 and be are defaults
> MULTILIB_OPTIONS = m64 mel # In makefile fragment
> MULTILIB_DIRNAMES = 64 el # In makefile fragment
> MULTILIB_OSDIRNAMES = m64=../lib64 # In makefile fragment
In my experience, for such cases it's best to list all multilibs
explicitly in MULTILIB_OSDIRNAMES, and then to specify
STARTFILE_PREFIX_SPEC as well along the lines of:
#define STARTFILE_PREFIX_SPEC \
"%{mabi=32: /usr/local/lib/ /lib/ /usr/lib/} \
%{mabi=n32: /usr/local/lib32/ /lib32/ /usr/lib32/} \
%{mabi=64: /usr/local/lib64/ /lib64/ /usr/lib64/}"
MULTILIB_OSDIRNAMES provides directory names used in two ways: relative to
$target/lib/ in the GCC installation, and relative to lib/ and usr/lib/ in
a sysroot. For the latter, we want names such as plain ../lib64, but
these cannot be used outside the sysroot because different multilibs would
be mapped to the same directory. Directories are searched both with and
without the multilib suffix, so it suffices if the directory without the
suffix is correct within the sysroot while the directory with the suffix
doesn't exist. STARTFILE_PREFIX_SPEC is used to ensure that a correct
unsuffixed directory is searched (instead of just lib/, usr/lib/ and those
with the full name from MULTILIB_OSDIRNAMES appended) within the sysroot.
> But when it looks for libgcc_s.so or libstdc++.so it is searching:
>
> <install-dir>/<target-name>/lib # 32 bits
> <install_dir>/<target-name>/lib/../lib64 # 64 bits
>
> It does not take into account SYSROOT_SUFFIX_SPEC. In fact when I
> do my build with this setup the little-endian libgcc_s.so files wind
> up overwriting the big-endian libgcc_s.so files so two of my
> libgcc_s.so files are completely missing from the install area.
GCC never installs anything inside the sysroot (it could be a read-only
mount of the target's root filesystem, for example). Listing all
multilibs explicitly (multilib=dir or multilib=!dir) in
MULTILIB_OSDIRNAMES allows you to ensure they don't overwrite each other.
--
Joseph S. Myers
[email protected]
