I think libatomic configure.ac / Makefile.am has the bits to copy here.

but the code is there, maybe it's confused by the subdirs?

Awesome - thanks for the pointer - will examine the subdirs problem simultaneously

May I please ping this?

One issue is that for some reason for example libm2cor/Makefile.am has

# Directory in which the compiler finds libraries etc.
libsubdir = $(libdir)/gcc/$(target_alias)/$(version)
# Used to install the shared libgcc.
slibdir = @slibdir@

but the generated Makefile.in has those re-ordered to

# Used to install the shared libgcc.
slibdir = @slibdir@
...
# Directory in which the compiler finds libraries etc.
libsubdir = $(libdir)/gcc/$(target_alias)/$(version)

it looks like substitutes are re-ordered early here.  But since at least
inst_slibdir isn't used that should be harmless, inst_libdir doesn't suffer
from this in the generated Makefile at least and I only see the
version missing.  Possibly because toolexeclibdir uses $(gcc_version) and
not $(version).

I'm testing replacing that with a canonical gcc_version everywhere.

Also honoring --with-gcc-major-version-only

The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:1cfaaa42296298ea2d2b22a93d3c8c17104e6cd3

commit r13-5255-g1cfaaa42296298ea2d2b22a93d3c8c17104e6cd3
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Jan 19 12:15:14 2023 +0100

    modula2/108144 - fix --enable-version-specific-runtime-libs
    
    The following fixes --enable-version-specific-runtime-libs for
    the modula2 target libraries.  The issue is that the install
    happens via for example
    
    toolexeclib_LTLIBRARIES = libm2cor.la
    
    and toolexeclibdir is set to $(toolexecdir)/$(gcc_version)$(MULTISUBDIR)
    but the Makefile.am do not define $(gcc_version) but instead
    $(version) which is used locally to define libsubdir.  The fix
    is to consistently define and use $(gcc_version), also properly
    supporting --with-gcc-major-version-only
    
            PR modula2/108144
    libgm2/
            * configure.ac: Add GCC_BASE_VER.
            * configure: Re-generate.
            * Makefile.am: Use @get_gcc_base_ver@ for gcc_version.
            * libm2cor/Makefile.am: Likewise.  Use gcc_version instead
            of version.
            * libm2iso/Makefile.am: Likewise.
            * libm2log/Makefile.am: Likewise.
            * libm2min/Makefile.am: Likewise.
            * libm2pim/Makefile.am: Likewise.
            * Makefile.in: Re-generate.
            * libm2cor/Makefile.in: Likewise.
            * libm2iso/Makefile.in: Likewise.
            * libm2log/Makefile.in: Likewise.
            * libm2min/Makefile.in: Likewise.
            * libm2pim/Makefile.in: Likewise.

This particular issue should be fixed now.

With the Richi's patch, I still see an issue with 32-bit .so files:

$ ~/Programming/gcc/configure --enable-languages=c,c++,m2 --prefix=/tmp/gcc --disable-libsanitizer --enable-valgrind-annotations --disable-bootstrap --with-system-zlib --with-gcc-major-version-only --enable-version-specific-runtime-libs
$ make
$ make install
...
$ find . -name libm2cor.so
./x86_64-pc-linux-gnu/libgm2/libm2cor/.libs/libm2cor.so
./x86_64-pc-linux-gnu/32/libgm2/libm2cor/.libs/libm2cor.so

while it's not installed into the destination folder:

$ find /tmp/gcc -name libm2cor.so
/tmp/gcc/lib64/gcc/x86_64-pc-linux-gnu/13/libm2cor.so

while .a files are installed (apparently multiple times):

$ find /tmp/gcc -name libm2cor.a
/tmp/gcc/lib64/gcc/x86_64-pc-linux-gnu/13/libm2cor.a
/tmp/gcc/lib64/gcc/x86_64-pc-linux-gnu/13/m2/m2cor/libm2cor.a
/tmp/gcc/lib64/gcc/x86_64-pc-linux-gnu/13/32/m2/m2cor/libm2cor.a

@Richi: Can you please take a look?

Isn't --enable-version-specific-runtime-libs completely broken anyway? See PR 32415

On Thu, 19 Jan 2023, redi at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108144
> 
> --- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
> Isn't --enable-version-specific-runtime-libs completely broken anyway? See PR
> 32415

Depends on what you call "completely broken" - the libgcc install is
"broken", yes.  But it could be fixed easily if somebody cared.

Hmm, so with --enable-version-specific-runtime-libs we install the 32bit multilib to the same location as the 64bit one.  Somehow MULTISUBDIR
ends up being empty even though it should be passed down into the subdirs.

The -recursive rules are quite hard to follow and I'm neither a make nor
automake expert here :/

Looking at libsanitizer I wonder why the libgm2 automake files are so complex :/

There definitely seems to be a lot of "dead" things but then somehow
magically the non-version-specific path is working.

Somehow for libsanitizer the ubsan Makefile has a tail

# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:
MULTISUBDIR = /32

but the libgm2/m2cor Makefile for example has not.

m2 doesn't do AM_PROG_LIBTOOL but instead LT_INIT, it looks like libgm2 mostly
cut&pasted from libgcc?

I'm trying some cleanups but that's just random edits without really knowing what I'm doing ...

I think all uses of $(inst_libdir)/$(MULTIDIR) should be replaced with $(toolexeclibdir) and the redundant multi settings removed.

A first round of "cleanups" leads to

$ find /tmp/gcc -name libm2cor.so
/tmp/gcc/lib/gcc/x86_64-pc-linux-gnu/13/libm2cor.so
/tmp/gcc/lib64/gcc/x86_64-pc-linux-gnu/13/libm2cor.so

an improvement(?!) but still not where we want to be ...

OK, it looks libgm2 lacks the magic invocation of config-ml.in.

The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:e61d43791e0943414d33c96de1dd4bfe5f611e29

commit r13-5284-ge61d43791e0943414d33c96de1dd4bfe5f611e29
Author: Richard Biener <rguenther@suse.de>
Date:   Fri Jan 20 12:27:50 2023 +0100

    modula2/108144 - Fix multilib install of libgm2
    
    The following adjusts libgm2 to properly use the multilib build
    infrastructure, thereby fixing the install with
    --enable-version-specific-runtime-libs
    
    In particular config-ml.pl needs to be applied to generated Makefiles
    as documented in the manual and we have to avoid clobbering the
    variables via make arguments.  The explicit install rules used different
    ways to construct the multilib dir which isn't necessary and breaks
    when MUTLIDIR is now finally set correctly.  Instead use
    $(toolexeclibdir).
    
    This results in some dead variables in the Makefile.am (and there were
    some before), I refrained from doing even more changes here.
    
    Verified with an install with and without --enable-version-specific-runtime-libs
    and checking the result.
    
            PR modula2/108144
    libgm2/
            * configure.ac: Apply config-ml.pl to the generated Makefiles.
            Set multilib_arg, use AM_PROG_LIBTOOL.
            * configure: Regenerate.
            * Makefile.am (AM_MAKEFLAGS): Do not override MULTI* flags.
            * Makefile.in: Regenerate.
            * libm2cor/Makefile.am: Install to $(toolexeclibdir)$(M2LIBDIR)
            rather than $(inst_libdir)/$(MULTIDIR)$(M2LIBDIR).
            * libm2iso/Makefile.am: Likewise.
            * libm2log/Makefile.am: Likewise.
            * libm2min/Makefile.am: Likewise.
            * libm2pim/Makefile.am: Likewise.
            * libm2cor/Makefile.in: Regenerate.
            * libm2iso/Makefile.in: Likewise.
            * libm2log/Makefile.in: Likewise.
            * libm2min/Makefile.in: Likewise.
            * libm2pim/Makefile.in: Likewise.

Fixed

I think it's still not correct with the latest patch:

$ pwd
/home/abuild/rpmbuild/BUILDROOT/gcc13-13.0.1+git5263-0.x86_64/usr/lib64/gcc/x86_64-suse-linux/13
$ ls -l libm2log.so*
lrwxrwxrwx 1 abuild abuild    18 Jan 20 14:53 libm2log.so -> libm2log.so.18.0.0
lrwxrwxrwx 1 abuild abuild    18 Jan 20 14:53 libm2log.so.18 -> libm2log.so.18.0.0
-rwxr-xr-x 1 abuild abuild 89000 Jan 20 14:53 libm2log.so.18.0.0

My impression is that the symlink target (versioned library) should be placed directly into /usr/lib64/. Similarly to other libs:

$ readlink -f libgo.so
/home/abuild/rpmbuild/BUILDROOT/gcc13-13.0.1+git5263-0.x86_64/usr/lib64/libgo.so.22.0.0

No, you need to amend

# move shared libs from versionspecific dir to main libdir
for libname in \
%if %{build_fortran}
  libgfortran \
...

for modula2

(In reply to Richard Biener from comment #18)
> No, you need to amend
> 
> # move shared libs from versionspecific dir to main libdir
> for libname in \
> %if %{build_fortran}
>   libgfortran \
> ...
> 
> for modula2

Oh, thanks for the note.

The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:47465fff9738b08796f4b52570fec49bbdbf3e57

commit r13-5288-g47465fff9738b08796f4b52570fec49bbdbf3e57
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Jan 23 11:14:05 2023 +0100

    modula2/108144 - fix mistake in previous change
    
    The previous change to avoid a duplicate multi directory
    caused the m2/m2{cor,iso,log,min,pim} installs to happen
    relative to the main library directory when not using
    --enable-version-specific-runtime-libs which doesn't match
    the drivers expectation where to find them.  The following
    fixes the original issue by simply dropping the duplicate
    multi directory since the one in the $(inst_libdir) variable
    now works.
    
    Tested by building and installing with and without
    --enable-version-specific-runtime-libs and compiling and
    linking a modula-2 testcase successfully with the installed
    compilers.
    
            PR modula2/108144
    libgm2/
            * libm2cor/Makefile.am: Revert previous change, instead
            drop the redundant $(MULTIDIR).
            * libm2iso/Makefile.am: Likewise.
            * libm2log/Makefile.am: Likewise.
            * libm2min/Makefile.am: Likewise.
            * libm2pim/Makefile.am: Likewise.
            * libm2cor/Makefile.in: Regenerate.
            * libm2iso/Makefile.in: Likewise.
            * libm2log/Makefile.in: Likewise.
            * libm2min/Makefile.in: Likewise.
            * libm2pim/Makefile.in: Likewise.