x86_64 gcc multilibs

[Ralf Corsepius]

On Mon, 2005-02-07 at 06:26 -0500, Jakub Jelinek wrote:
> On Mon, Feb 07, 2005 at 12:10:37PM +0100, Ralf Corsepius wrote:
> > Hi,
> > 
> > Is it correct, that FC3's gcc on x86_64 uses these multilibs:
> > 
> > $ x86_64-redhat-linux-gcc  -print-multi-lib
> > .;
> > 32;@m32
> > 
> > IMO, this is wrong and should either be 
> > (assuming . matching -m64 | lib64)
> > .;
> > 32;../lib
> > 
> > or (assuming . matching -m32 | lib)
> > .;
> > 64;../lib64
> > 
> > If x86_64 gcc was using one of the latter muliblib-sets,
> >  gcc -m64 -L/xxx/lib
> > would automatically pickup m64 compiled libs from /xxx/lib/../lib64,
> > instead of those from /xxx/lib.
> > 
> > Unfortunately I don't have access to x86_64 systems :-(
> 
> Nope, it is correct.  -print-multi-lib is about what multilib combinations
> exists and the relative path they are using inside of /usr/lib/gcc/*/*/
> etc.

Hmm, all multilib'ed OSes I have been using sofar used the relative path
being contained in the second half of -print-multi-libs, as part of
their library search path.

This also is what I see in genmultilib:

...
# The optional seventh argument is a list of OS subdirectory names.
# The format is either the same as of the second argument, or a set of
# mappings. When it is the same as the second argument, it describes
# the multilib directories using OS conventions, rather than GCC
# conventions.  When it is a set of mappings of the form gccdir=osdir,
# the left side gives the GCC convention and the right gives the
# equivalent OS defined location.  If the osdir part begins with a !,
# the os directory names are used exclusively.  Use the mapping when
# there is no one-to-one equivalence between GCC levels and the OS.

# The last option should be "yes" if multilibs are enabled.  If it is
not
# "yes", all GCC multilib dir names will be ".".

# The output looks like
#   #define MULTILIB_MATCHES "\
#   SUBDIRECTORY OPTIONS;\
#   ...
#   "
#
...
# Here is an example (this is from the actual sparc64 case):
#   genmultilib 'm64/m32 mno-app-regs|mcmodel=medany' '64 32 alt'
#               'mcmodel?medany=mcmodel?medmid' 'm32/mno-app-regs*
m32/mcmodel=
#               '' 'm32/!m64/mno-app-regs m32/!m64/mcmodel=medany'
#               '../lib64 ../lib32 alt' yes
# This produces:
#   ". !m64 !m32 !mno-app-regs !mcmodel=medany;",
#   "64:../lib64 m64 !m32 !mno-app-regs !mcmodel=medany;",
#   "32:../lib32 !m64 m32 !mno-app-regs !mcmodel=medany;",
#   "alt !m64 !m32 mno-app-regs mcmodel=medany;",
#   "alt !m64 !m32 mno-app-regs !mcmodel=medany;",
#   "alt !m64 !m32 !mno-app-regs mcmodel=medany;",
#   "64/alt:../lib64/alt m64 !m32 mno-app-regs mcmodel=medany;",
#   "64/alt:../lib64/alt m64 !m32 mno-app-regs !mcmodel=medany;",
#   "64/alt:../lib64/alt m64 !m32 !mno-app-regs mcmodel=medany;",
#
# The effect is that `gcc -mno-app-regs' (for example) will append "alt"
# to the directory name when searching for libraries or startup files
and
# `gcc -m32 -mcmodel=medany' (for example) will append "32/alt". Also
note
# that exclusion above is moot, unless the compiler had a default of -
m32,
# which would mean that all of the "alt" directories (not the 64/alt
ones)
# would be ignored (not generated, nor used) since the exclusion also
# matches the multilib_default args.

I read this as:
x86_64-redhat-gcc -m64
should on ../lib64

>   -print-multi-os-directory is what tells you the relative path
> used to search multilib directories that are under OS rather than GCC's
> convention.
> For gcc that defaults to -m64 you get:
> gcc -print-multi-os-directory -m32; gcc -print-multi-os-directory -m64; gcc -print-multi-os-directory
> ../lib
> ../lib64
> ../lib64


Then something else must be broken. I received complaints about programs
trying to be linked as
x86_64-redhat-gcc -m64 ... -L/usr/X11R6/lib
to complain about 32 libs. 

This indicates that -m64 does not search on ../lib64
 
Ralf