'./configure --disable-multilib' and 'gcc -print-multi-os-directory' interaction

'./configure --disable-multilib' and 'gcc -print-multi-os-directory' interaction

[Sergei Trofimovich]

x86_64-linux-musl targets do not support multilib layout as-is
and usually expects libdir=lib. glibc target usually uses libdir=lib64.

In https://bugs.gentoo.org/675954 (also touched on https://gcc.gnu.org/PR90077)
Gentoo discovered the following discrepancy when gcc is built with --disable-multilib:

1. --disable-multilib
  ../gcc/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-gentoo-linux-musl --disable-multilib
  $ gcc/xgcc -B. -print-multi-os-directory
  ../lib64
Wouldn't it be reasonable to have '.' instead of '../lib64' here?

2. --disable-multilib --with-multilib-list=
  ../gcc/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-gentoo-linux-musl --disable-multilib --with-multilib-list=
  $ gcc/xgcc -B. -print-multi-os-directory
  .

3. --disable-multilib --with-multilib-list=m64
  ../gcc/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-gentoo-linux-musl --disable-multilib --with-multilib-list=m64
  $ gcc/xgcc -B. -print-multi-os-directory
  ../lib64

Currently Gentoo uses [3.] and experiences problems in 'meson'
build systems which extract libdir via 'gcc -print-multi-os-directory'
and observed "lib" != "lib64" mismatch.

I have a few questions:

Q1. Are all [1.]/[2.]/[3.] behaviors correct and expected? Should
  '--with-multilib-list=' (empty) be always accompanied with '--disable-multilib'
  to avoid multi-os-dir=../lib64? Or should gcc be tweaked to disallow
  contradicting cases like [3.]?

Q2. What is the best way for *-musl* targets to just default to 'lib'
  layout at least for explicit '--disable-multilib' case? Just advise users
  do [2.] or should gcc be tweaked?

Q3. Is '--disable-multilib --with-multilib-list=m64' a sensible configuration at all?
  Should it be an equivalent of '--disable-multilib --with-multilib-list='
  (multi-os-dir=.) with default m64 ABI?
  Or should it be an equivalent of '--enable-multilib'
  (multi-os-dir=../lib64) with default m64 ABI?

Thank you!

-- 

  Sergei

Re: './configure --disable-multilib' and 'gcc -print-multi-os-directory' interaction

[Andreas Schwab]

On Mär 28 2020, Sergei Trofimovich via Gcc wrote:

> x86_64-linux-musl targets do not support multilib layout as-is
> and usually expects libdir=lib. glibc target usually uses libdir=lib64.

If x86_64-linux-musl doesn't support multilib then it should not use
i386/t-linux64 as tmake_file.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: './configure --disable-multilib' and 'gcc -print-multi-os-directory' interaction

[Sergei Trofimovich]

On Sat, 28 Mar 2020 11:35:36 +0100
Andreas Schwab <schwab@linux-m68k.org> wrote:

> On Mär 28 2020, Sergei Trofimovich via Gcc wrote:
> 
> > x86_64-linux-musl targets do not support multilib layout as-is
> > and usually expects libdir=lib. glibc target usually uses libdir=lib64.  
> 
> If x86_64-linux-musl doesn't support multilib then it should not use
> i386/t-linux64 as tmake_file.

i386/t-linux64 is also be used for (debian's?) multiarch and not just multilib.
From https://gcc.gnu.org/PR90077#c2 I assume multiarch still works
    MULTILIB_OSDIRNAMES = m64=../lib64:x86_64-linux-musl
and happens to use lib64, yes? Don't know how multiarch maps to real directories.

https://wiki.debian.org/Multiarch/LibraryPathOverview claims result should
end up being.
    /usr/lib/$(multiarch)

Looking at https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config.gcc;h=13e3cb753e2c6b9b326d182ffb38944fb44454a5;hb=HEAD#l1916
it does not seem like just dropping it for '*-musl*' will work.

-- 

  Sergei