[Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs

[Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs

[marxin at gcc dot gnu.org]

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

            Bug ID: 108144
           Summary: m2 does not respect
                    --enable-version-specific-runtime-libs
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: modula2
          Assignee: gaius at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

When I build Modula-2 with --enable-version-specific-runtime-libs and install
it, I get:

$ ~/bin/gcc> find . -name '*\.so*' | sort
...
./lib64/gcc/x86_64-pc-linux-gnu/libm2cor.so
./lib64/gcc/x86_64-pc-linux-gnu/libm2cor.so.17
./lib64/gcc/x86_64-pc-linux-gnu/libm2cor.so.17.0.0
./lib64/gcc/x86_64-pc-linux-gnu/libm2iso.so
./lib64/gcc/x86_64-pc-linux-gnu/libm2iso.so.17
./lib64/gcc/x86_64-pc-linux-gnu/libm2iso.so.17.0.0
./lib64/gcc/x86_64-pc-linux-gnu/libm2log.so
./lib64/gcc/x86_64-pc-linux-gnu/libm2log.so.17
./lib64/gcc/x86_64-pc-linux-gnu/libm2log.so.17.0.0
./lib64/gcc/x86_64-pc-linux-gnu/libm2min.so
./lib64/gcc/x86_64-pc-linux-gnu/libm2min.so.17
./lib64/gcc/x86_64-pc-linux-gnu/libm2min.so.17.0.0
./lib64/gcc/x86_64-pc-linux-gnu/libm2pim.so
./lib64/gcc/x86_64-pc-linux-gnu/libm2pim.so.17
./lib64/gcc/x86_64-pc-linux-gnu/libm2pim.so.17.0.0

while other libraries are properly placed under:

...
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libatomic.so.1
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libatomic.so.1.2.0
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libgomp.so
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libgomp.so.1
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libgomp.so.1.0.0
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libitm.so
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libitm.so.1
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libitm.so.1.0.0
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libquadmath.so
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libquadmath.so.0
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libquadmath.so.0.0.0
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libssp.so
./lib64/gcc/x86_64-pc-linux-gnu/13.0.0/libssp.so.0
...

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Target Milestone|---                         |13.0
   Last reconfirmed|                            |2022-12-16

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think libatomic configure.ac / Makefile.am has the bits to copy here.

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
but the code is there, maybe it's confused by the subdirs?

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

[gaius at gcc dot gnu.org]

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

--- Comment #3 from Gaius Mulley <gaius at gcc dot gnu.org> ---
Awesome - thanks for the pointer - will examine the subdirs problem
simultaneously

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
May I please ping this?

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|gaius at gcc dot gnu.org           |rguenth at gcc dot gnu.org

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
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.

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Also honoring --with-gcc-major-version-only

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
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.

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
This particular issue should be fixed now.

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |---
             Status|RESOLVED                    |REOPENED

--- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> ---
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?

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

[redi at gcc dot gnu.org]

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

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> ---
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.

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at gcc dot gnu.org

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
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 ...

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
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 ...

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |ASSIGNED

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, it looks libgm2 lacks the magic invocation of config-ml.in.

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
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.

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #17 from Martin Liška <marxin at gcc dot gnu.org> ---
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

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> ---
No, you need to amend

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

for modula2

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

[marxin at gcc dot gnu.org]

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

--- Comment #19 from Martin Liška <marxin at gcc dot gnu.org> ---
(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.

[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs

[cvs-commit at gcc dot gnu.org]

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

--- Comment #20 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
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.