This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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-


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]