* [Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
2022-12-16 11:34 [Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs marxin at gcc dot gnu.org
@ 2022-12-16 11:36 ` marxin at gcc dot gnu.org
2022-12-16 11:51 ` rguenth at gcc dot gnu.org
` (19 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: marxin at gcc dot gnu.org @ 2022-12-16 11:36 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
2022-12-16 11:34 [Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs marxin at gcc dot gnu.org
2022-12-16 11:36 ` [Bug modula2/108144] " marxin at gcc dot gnu.org
@ 2022-12-16 11:51 ` rguenth at gcc dot gnu.org
2022-12-16 11:55 ` rguenth at gcc dot gnu.org
` (18 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-12-16 11:51 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
2022-12-16 11:34 [Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs marxin at gcc dot gnu.org
2022-12-16 11:36 ` [Bug modula2/108144] " marxin at gcc dot gnu.org
2022-12-16 11:51 ` rguenth at gcc dot gnu.org
@ 2022-12-16 11:55 ` rguenth at gcc dot gnu.org
2022-12-16 12:18 ` gaius at gcc dot gnu.org
` (17 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-12-16 11:55 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
2022-12-16 11:34 [Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs marxin at gcc dot gnu.org
` (2 preceding siblings ...)
2022-12-16 11:55 ` rguenth at gcc dot gnu.org
@ 2022-12-16 12:18 ` gaius at gcc dot gnu.org
2023-01-13 9:25 ` marxin at gcc dot gnu.org
` (16 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: gaius at gcc dot gnu.org @ 2022-12-16 12:18 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
2022-12-16 11:34 [Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs marxin at gcc dot gnu.org
` (3 preceding siblings ...)
2022-12-16 12:18 ` gaius at gcc dot gnu.org
@ 2023-01-13 9:25 ` marxin at gcc dot gnu.org
2023-01-19 10:18 ` rguenth at gcc dot gnu.org
` (15 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: marxin at gcc dot gnu.org @ 2023-01-13 9:25 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
2022-12-16 11:34 [Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs marxin at gcc dot gnu.org
` (4 preceding siblings ...)
2023-01-13 9:25 ` marxin at gcc dot gnu.org
@ 2023-01-19 10:18 ` rguenth at gcc dot gnu.org
2023-01-19 10:26 ` rguenth at gcc dot gnu.org
` (14 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-01-19 10:18 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
2022-12-16 11:34 [Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs marxin at gcc dot gnu.org
` (5 preceding siblings ...)
2023-01-19 10:18 ` rguenth at gcc dot gnu.org
@ 2023-01-19 10:26 ` rguenth at gcc dot gnu.org
2023-01-19 13:48 ` cvs-commit at gcc dot gnu.org
` (13 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-01-19 10:26 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
2022-12-16 11:34 [Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs marxin at gcc dot gnu.org
` (6 preceding siblings ...)
2023-01-19 10:26 ` rguenth at gcc dot gnu.org
@ 2023-01-19 13:48 ` cvs-commit at gcc dot gnu.org
2023-01-19 13:49 ` rguenth at gcc dot gnu.org
` (12 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-01-19 13:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
2022-12-16 11:34 [Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs marxin at gcc dot gnu.org
` (7 preceding siblings ...)
2023-01-19 13:48 ` cvs-commit at gcc dot gnu.org
@ 2023-01-19 13:49 ` rguenth at gcc dot gnu.org
2023-01-19 14:52 ` marxin at gcc dot gnu.org
` (11 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-01-19 13:49 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
2022-12-16 11:34 [Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs marxin at gcc dot gnu.org
` (8 preceding siblings ...)
2023-01-19 13:49 ` rguenth at gcc dot gnu.org
@ 2023-01-19 14:52 ` marxin at gcc dot gnu.org
2023-01-19 15:23 ` redi at gcc dot gnu.org
` (10 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: marxin at gcc dot gnu.org @ 2023-01-19 14:52 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
2022-12-16 11:34 [Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs marxin at gcc dot gnu.org
` (9 preceding siblings ...)
2023-01-19 14:52 ` marxin at gcc dot gnu.org
@ 2023-01-19 15:23 ` redi at gcc dot gnu.org
2023-01-20 8:35 ` rguenther at suse dot de
` (9 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: redi at gcc dot gnu.org @ 2023-01-19 15:23 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
2022-12-16 11:34 [Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs marxin at gcc dot gnu.org
` (10 preceding siblings ...)
2023-01-19 15:23 ` redi at gcc dot gnu.org
@ 2023-01-20 8:35 ` rguenther at suse dot de
2023-01-20 9:46 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenther at suse dot de @ 2023-01-20 8:35 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
2022-12-16 11:34 [Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs marxin at gcc dot gnu.org
` (11 preceding siblings ...)
2023-01-20 8:35 ` rguenther at suse dot de
@ 2023-01-20 9:46 ` rguenth at gcc dot gnu.org
2023-01-20 10:26 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-01-20 9:46 UTC (permalink / raw)
To: gcc-bugs
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 ...
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
2022-12-16 11:34 [Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs marxin at gcc dot gnu.org
` (12 preceding siblings ...)
2023-01-20 9:46 ` rguenth at gcc dot gnu.org
@ 2023-01-20 10:26 ` rguenth at gcc dot gnu.org
2023-01-20 10:35 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-01-20 10:26 UTC (permalink / raw)
To: gcc-bugs
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 ...
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
2022-12-16 11:34 [Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs marxin at gcc dot gnu.org
` (13 preceding siblings ...)
2023-01-20 10:26 ` rguenth at gcc dot gnu.org
@ 2023-01-20 10:35 ` rguenth at gcc dot gnu.org
2023-01-23 7:21 ` cvs-commit at gcc dot gnu.org
` (5 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-01-20 10:35 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
2022-12-16 11:34 [Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs marxin at gcc dot gnu.org
` (14 preceding siblings ...)
2023-01-20 10:35 ` rguenth at gcc dot gnu.org
@ 2023-01-23 7:21 ` cvs-commit at gcc dot gnu.org
2023-01-23 7:22 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-01-23 7:21 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
2022-12-16 11:34 [Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs marxin at gcc dot gnu.org
` (15 preceding siblings ...)
2023-01-23 7:21 ` cvs-commit at gcc dot gnu.org
@ 2023-01-23 7:22 ` rguenth at gcc dot gnu.org
2023-01-23 9:41 ` marxin at gcc dot gnu.org
` (3 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-01-23 7:22 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
2022-12-16 11:34 [Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs marxin at gcc dot gnu.org
` (16 preceding siblings ...)
2023-01-23 7:22 ` rguenth at gcc dot gnu.org
@ 2023-01-23 9:41 ` marxin at gcc dot gnu.org
2023-01-23 9:56 ` rguenth at gcc dot gnu.org
` (2 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: marxin at gcc dot gnu.org @ 2023-01-23 9:41 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
2022-12-16 11:34 [Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs marxin at gcc dot gnu.org
` (17 preceding siblings ...)
2023-01-23 9:41 ` marxin at gcc dot gnu.org
@ 2023-01-23 9:56 ` rguenth at gcc dot gnu.org
2023-01-23 10:05 ` marxin at gcc dot gnu.org
2023-01-23 10:19 ` cvs-commit at gcc dot gnu.org
20 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-01-23 9:56 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
2022-12-16 11:34 [Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs marxin at gcc dot gnu.org
` (18 preceding siblings ...)
2023-01-23 9:56 ` rguenth at gcc dot gnu.org
@ 2023-01-23 10:05 ` marxin at gcc dot gnu.org
2023-01-23 10:19 ` cvs-commit at gcc dot gnu.org
20 siblings, 0 replies; 22+ messages in thread
From: marxin at gcc dot gnu.org @ 2023-01-23 10:05 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
2022-12-16 11:34 [Bug modula2/108144] New: m2 does not respect --enable-version-specific-runtime-libs marxin at gcc dot gnu.org
` (19 preceding siblings ...)
2023-01-23 10:05 ` marxin at gcc dot gnu.org
@ 2023-01-23 10:19 ` cvs-commit at gcc dot gnu.org
20 siblings, 0 replies; 22+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-01-23 10:19 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread