This is the mail archive of the 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]

Re: Multilib and Linux.

> > The scheme I had in mind was:
> > have /lib, /usr/lib, /usr/X11R6/lib for the 32bit ABI shared & static libraries
> > /lib64, /usr/lib64, /usr/X11R6/lib64 for the 64bit ABI shared & static libraries
> /lib and /lib/foo64 were suggested for other 32/64 targets.
> Also are you suggesting for any library directory, /foo/bar/lib, we
> have /foo/bar/lib for 32bit and /foo/bar/lib64 for 64bit?

Yep. That's the Irix way of doing things. I like it better than Sun's
/lib and /lib/sparcv9/
Basically, I think we're still in a phase where we can decide on some
standard and maybe even put it into FSSTND.

> So are you saying we never seach /usr/lib for 64bit? It was suggested
> that /usr/lib was searched as a fallback for 64bit. But it is very
> tricky and may lead to problems like:
> You have in /foo/bar/lib and /bar/lib64, what do you get
> with
> # gcc .... -L/foo/bar -L/bar/lib64
> Please send me the proposal on the behavior of linker on
> /foo/bar/lib and /foo/bar/lib64.

I thought along the lines of having some ABI checking routine which would
ldfile_try_open_bfd call before returning true and if it would tell it the
ABI is wrong, then it would close the bfd and return false, so it would be
searching further in the search paths.
So, if I do gcc ... -L/foo/bar/lib -L/foo/bar/lib64 and /foo/bar/lib{,64}
both contain, then if the one in /foo/bar/lib is 32bit ABI and
we're compiling for the 64bit ABI, then the one in /foo/bar/lib64 will be
chosen. Mixing of 32bit and 64bit ABI libraries/objects will not work, at
least on the sparc.

> BTW, what is the default ABI, 32bit or 64bit? How do you control
> it?

I thought about making it dependent on uname -m. sparc64 will have 64bit
ABI, sparc will have 32bit ABI. As of now, there is no code to do this uname
stuff, so the default depends on how one configures gcc or binutils.
egcs already handles multilibs for us, so one can change the default by
on the gcc command line. For ld and as, if one calls it explicitely, one
must use proper options -m elf64_sparc resp. -64 or -m elf32_sparc resp.
Now, we have a tiny program sparc32, which creates a 32bit environment on
sparc64 by making all child processes see uname -m sparc, so that e.g. all
configure scripts and stuff like that work.

> It looks like more than one Linux targets which have to deal with
> 32bit/64bit ABIs. We should have a common strategy to deal with
> all those issues. Should we create a mailing list for it?


Jakub Jelinek | |
Administrator of SunSITE Czech Republic, MFF, Charles University
UltraLinux  |  |
Linux version 2.2.5 on a sparc64 machine (3958.37 BogoMips)

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