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
