[Bug target/121998] --disable-multilib doesn't work if provision for multilib has been made.

[mark.dunn.and.sharon.king at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121998

--- Comment #6 from mark dunn <mark.dunn.and.sharon.king at gmail dot com> ---
I am sure that a lot of thought and effort has gone into both multilib and
multiarch to ensure they were compatible with the file hierachy standard.

/lib : Essential shared libraries and kernel modules
The /lib directory contains those shared library images needed to boot the
system and run the commands in the root filesystem, ie. by binaries in /bin
and /sbin.Shared libraries that are only necessary for binaries in /usr
(such as any X Window binaries) must not be in /lib. Only the shared
libraries required to run binaries in /bin and /sbin
At least one of each of the following filename patterns are required (they
may be files, or symbolic links):
libc.so.* The dynamically-linked C library (optional)
ld* The execution time linker/loader (optional)

/lib<qual> : Alternate format essential shared libraries (optional)
There may be one or more variants of the /lib directory on systems which
support more than one binary format requiring separate libraries.This is
commonly used for 64-bit or 32-bit support on systems which support
multiple binary formats, but require libraries of the same name. In this
case, /lib32 and /lib64 might be the library directories, and /lib a
symlink to one of them.

/usr/lib : Libraries for programming and packages
/usr/lib includes object files and libraries. On some systems, it may also
include internal binaries that are not intended to be executed directly by
users or shell scripts.
Applications may use a single subdirectory under /usr/lib. If an
application uses a subdirectory, all architecture-dependent data
exclusively used by the application must be placed within that subdirectory.

So I find it difficult to understand the technical arguments
1) Why you wouldn't want to allow this complexity to be removed if it was
not required (or you wish to switch to a different solution)
2) How the removal could possibly be incompatible, when so much effort has
been made to ensure its compatibility.

I reported a bug, like a good open source citizen should try to do.
I have a patch which works for me, so how you respond to the report is up
to you.

On Fri, 19 Sept 2025 at 22:24, pinskia at gcc dot gnu.org <
gcc-bugzilla@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121998
>
> --- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> (In reply to mark dunn from comment #4)
> > What is the expected behaviour of --disable-multilib in terms of library
> > names?
>
> None. But note in your case it is multiarch anyways so maybe you want
> --enable-multiarch instead.
>
>
> > I expected it to not differentiate between /lib32 and /lib64 instead just
> > revert to /lib or /usr/lib  depending on context.
>
> Nope, that is not how aarch64 and x86_64 work.
>
> >
> > I pointed out that --disable-multilib can NEVER have an effect if the
> > provision for multilib has been made.MULTILIB_OSDIRNAMES
> > In that case what is the point of '--disable-multilib' ?
>
> in the case of x86_64 to disable i686 libraries and in the case of aarch64
> disable ilp32 libraries (note ilp32 is deprecated but lib64 was used
> before to
> support having arm and aarch64 sysroot as one).
>
> --
> You are receiving this mail because:
> You reported the bug.