This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
MULTILIB_OSDIRNAMES trouble
- From: "Andreas Krebbel" <Andreas dot Krebbel at de dot ibm dot com>
- To: gcc at gcc dot gnu dot org
- Date: Wed, 4 Jun 2008 13:30:29 +0200
- Subject: MULTILIB_OSDIRNAMES trouble
Hello,
I'm experimenting with a hardware dfp libgcc_s for S/390. The target
is to have an additional variant of that lib built using the multilib
machinery.
Regarding this I'm wondering how to set MULTILIB_OSDIRNAMES correctly.
This variable is usually set in a makefile fragment in the back end
directory to tell GCC about the location of the correct libc and its
crt files - right?! Besides this it is also used for the target
location of libgcc_s.so. Unfortunately in my case I think I need two
distinct directories here.
Whether libgcc_s is compiled with hw dfp or not does not affect the
ABI. So I don't need - and don't want - an additional variant of libc
for dfp but I want the new libgcc_s variant to be installed in a
separate subdirectory. As I've written above setting
MULTILIB_OSDIRNAMES affects both :( If I set MULTILIB_OSDIRNAMES to
"../lib64 ../lib dfp" the libgcc_s would get installed correctly but
the link step of the 64 bit version fails since no crt files can be
found under /usr/lib64/dfp what makes ld to default to /usr/lib/ which
does not contain the 64 bit crt files.
If I don't set MULTILIB_OSDIRNAMES for dfp just leaving it as
"../lib64 ../lib" the build and link steps do fine but the resulting
hardware and software dfp libgcc_s are all installed in the lib64 and
lib dirs overwriting each other.
Does anybody has a hint how to solve this? Perhaps any spec file
magic using the SPECS variable in the makefile fragment?
Bye,
-Andreas-