[Bug libquadmath/112963] New: [14 Regression] Incorrect linking of libquadmath since r14-4863

[Bug libquadmath/112963] New: [14 Regression] Incorrect linking of libquadmath since r14-4863

[jakub at gcc dot gnu.org]

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

            Bug ID: 112963
           Summary: [14 Regression] Incorrect linking of libquadmath since
                    r14-4863
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libquadmath
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Since r14-4863-g538dcde872abba589b3c8a57181bd7f91018c67a libquadmath is linked
incorrectly on Linux, without the required libm.so.6 DT_NEEDED entry, even when
it
calls libm.so.6 signgam, sqrt and on powerpc64le-linux also __sqrtieee128
entrypoints.
Short reproducer reduced from libtool's testsuite on powerpc64le-linux:

( echo '      subroutine a1(res)'; echo '      integer*4 res'; echo '     
res=1'; echo '      return'; echo '      end' ) > a1.f; sed 's/1/2/g' < a1.f >
a2.f; ( echo '      program main'; echo '      integer*4 res'; echo '      call
a1(res)'; echo '      call a2(res)'; echo '      end' ) > main2.f; rm -rf
.libs; mkdir .libs; gfortran -O2 -mcpu=power8 -c a1.f -fPIC -o .libs/a1.o;
gfortran -O2 -mcpu=power8 -c a2.f -fPIC -o .libs/a2.o; gfortran -O2
-mcpu=power8 -c main2.f -fPIC -o .libs/main2.o; ar cr .libs/liba1.a .libs/a1.o;
ranlib .libs/liba1.a; ar cr .libs/liba2.a .libs/a2.o; ranlib .libs/liba2.a;
gfortran -shared -fPIC -Wl,--whole-archive ./.libs/liba1.a ./.libs/liba2.a
-Wl,--no-whole-archive -lgfortran -lm -lgcc_s -lquadmath -lm -lgcc_s -lc
-lgcc_s -O2 -mcpu=power8 -Wl,-z -Wl,relro -Wl,--as-needed -Wl,--build-id=sha1
-Wl,-soname -Wl,liba12.so.0 -o .libs/liba12.so.0.0.0; ln -sf liba12.so.0.0.0
.libs/liba12.so.0; ln -sf liba12.so.0.0.0 .libs/liba12.so; gfortran -O2
-mcpu=power8 -Wl,-z -Wl,relro -Wl,--as-needed -Wl,--build-id=sha1 -o .libs/main
.libs/main2.o ./.libs/liba12.so -Wl,-rpath,.libs/; .libs/main
This segfaults now, the above can be compiled even with gcc 13 and/or run
against gcc 13 libgfortran.so.5 and/or libgcc_s.so.1, the only thing for the
crash that matters is whether it dynamically links against gcc 13
libquadmath.so.0 (then it works) or gcc 14 libquadmath.so.0 (then it crashes).

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0
                 CC|                            |iains at gcc dot gnu.org
           Priority|P3                          |P1

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

[schwab@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
How did that work before r14-4825-g6a6d3817afa02b?

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe <iains at gcc dot gnu.org> ---

r14-4825-g6a6d3817afa02b, (adding @rpath support) was not intended to change
the behaviour of libc handling, but as noted a rebase error left that in
(probably because both changes acted on the link).

So the unwanted part of change removed the unconditional '-lm' from the link
line and replaced it with $(LIBM) which was derived from the AC_CHECK_LIBM
(which apparently breaks bare metal).

When I reverted the use of AC_CHECK_LIBM in r14-4863-g538dcde872a, I should
also have reverted the use of $(LIBM) to -lm in libquadmath_la_LDFLAGS.

so I need to set up to test the following on the various targets - does this
fix it for you?

diff --git a/libquadmath/Makefile.am b/libquadmath/Makefile.am
index 0d02c95e738..2aaa0f95b5b 100644
--- a/libquadmath/Makefile.am
+++ b/libquadmath/Makefile.am
@@ -42,7 +42,7 @@ libquadmath_darwin_rpath = -Wc,-nodefaultrpaths
 libquadmath_darwin_rpath += -Wl,-rpath,@loader_path
 endif
 libquadmath_la_LDFLAGS = -version-info `grep -v '^\#'
$(srcdir)/libtool-version` \
-       $(version_arg) $(lt_host_flags) $(LIBM) $(libquadmath_darwin_rpath)
+       $(version_arg) $(lt_host_flags) -lm $(libquadmath_darwin_rpath)
 libquadmath_la_DEPENDENCIES = $(version_dep) $(libquadmath_la_LIBADD)

 nodist_libsubinclude_HEADERS = quadmath.h quadmath_weak.h
diff --git a/libquadmath/Makefile.in b/libquadmath/Makefile.in
index dbcafb57e5b..8d4ea034c15 100644
--- a/libquadmath/Makefile.in
+++ b/libquadmath/Makefile.in
@@ -466,7 +466,7 @@ AUTOMAKE_OPTIONS = foreign info-in-builddir
 @BUILD_LIBQUADMATH_TRUE@@ENABLE_DARWIN_AT_RPATH_TRUE@libquadmath_darwin_rpath
= -Wc,-nodefaultrpaths \
 @BUILD_LIBQUADMATH_TRUE@@ENABLE_DARWIN_AT_RPATH_TRUE@  -Wl,-rpath,@loader_path
 @BUILD_LIBQUADMATH_TRUE@libquadmath_la_LDFLAGS = -version-info `grep -v '^\#'
$(srcdir)/libtool-version` \
-@BUILD_LIBQUADMATH_TRUE@       $(version_arg) $(lt_host_flags) $(LIBM)
$(libquadmath_darwin_rpath)
+@BUILD_LIBQUADMATH_TRUE@       $(version_arg) $(lt_host_flags) -lm
$(libquadmath_darwin_rpath)

 @BUILD_LIBQUADMATH_TRUE@libquadmath_la_DEPENDENCIES = $(version_dep)
$(libquadmath_la_LIBADD)
 @BUILD_LIBQUADMATH_TRUE@nodist_libsubinclude_HEADERS = quadmath.h
quadmath_weak.h

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

[iains at gcc dot gnu.org]

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

--- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Andreas Schwab from comment #1)
> How did that work before r14-4825-g6a6d3817afa02b?

I suppose, unconditional adding of '-lm' is not a problem to the affected bare
metal targets but using the AC_CHECK_LIBM is, I still have to set up to do the
testing.

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #3)
> (In reply to Andreas Schwab from comment #1)
> > How did that work before r14-4825-g6a6d3817afa02b?
> 
> I suppose, unconditional adding of '-lm' is not a problem to the affected
> bare metal targets but using the AC_CHECK_LIBM is, I still have to set up to
> do the testing.

For bare metal targets, -lm is ignored because shared libraries are not built
...

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I believe it should fix it indeed.
On most targets, linking by g++ or gfortran drivers already adds -lm:
find cp/g++spec.cc fortran/gfortranspec.cc config -type f | xargs grep -w
MATH_LIBRARY
cp/g++spec.cc:#ifndef MATH_LIBRARY
cp/g++spec.cc:#define MATH_LIBRARY "m"
fortran/gfortranspec.cc:#ifndef MATH_LIBRARY
fortran/gfortranspec.cc:#define MATH_LIBRARY "m"
config/vms/vms.h:#define MATH_LIBRARY ""
config/s390/tpf.h:#define MATH_LIBRARY "CLBM"
config/bpf/bpf.h:#define MATH_LIBRARY ""
config/i386/cygming.h:#undef MATH_LIBRARY
config/i386/cygming.h:#define MATH_LIBRARY ""
config/vx-common.h:#define MATH_LIBRARY ""
config/darwin.h:#define MATH_LIBRARY ""
I bet we don't really support libquadmath say on s390 tpf and for many other
targets we also don't build libquadmath, that is done only on targets with
__float128 support.
One question is for the "" targets (mainly Darwin, VxWorks, Cygwin, Mingw)
whether ""
MATH_LIBRARY is there just because it isn't needed to link against -lm, or
whether it is because linking against it is not possible.

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> ---
I cannot peak for the others, but Darwin does not need '-lm' because it is part
of libc [libSystem] (adding -lm actually symlinks to libSystem and alters the
effective library order on the link line so I'd prefer to avoid it, if
possible).  We managed to make this work for libgfortran, I need to check how.

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #6)
> I cannot peak for the others, but Darwin does not need '-lm' because it is
> part of libc [libSystem] (adding -lm actually symlinks to libSystem and
> alters the effective library order on the link line so I'd prefer to avoid
> it, if possible).  We managed to make this work for libgfortran, I need to
> check how.

libgfortran seems to use the LT_LIB_M macro for that (but I believe that is
just a newer name for AC_CHECK_LIBM).
libgfortran has
if test "$build" != "$host"; then
  LIBGFOR_IS_NATIVE=false
  GCC_NO_EXECUTABLES
else
  LIBGFOR_IS_NATIVE=true
fi
and later uses LT_LIB_M, while
libquadmath has GCC_NO_EXECUTABLES unconditionally.
libstdc++-v3 uses something like libgfortran with extra condition for some
Darwin crosses.

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

[iains at gcc dot gnu.org]

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

--- Comment #8 from Iain Sandoe <iains at gcc dot gnu.org> ---
I propose to test the patch at comment #2 as a step to restore the original
behaviour.  It would be nice to make the libm use configurable (as per
libgfortran or libstdc++) as a separate issue.

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ok with me, I'll include it tonight in my x86_64/i686-linux bootstraps.

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
BTW, yet another option  would be to just
LIBM=
case $host in
*-*-beos* | *-*-cegcc* | *-*-cygwin* | *-*-haiku* | *-*-pw32* | *-*-darwin*)
  # These system don't have libm, or don't need it
  ;;
*)
  LIBM=-lm
  ;;
esac
AC_SUBST([LIBM])
i.e. copy&paste libtool AC_CHECK_LIBM without that AC_CHECK_LIB part (and
without *-ncr-sysv* entry which we don't support in GCC AFAIK), so something in
between using -lm unconditionally and not using it on targets which don't
really need it.

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #10)
> BTW, yet another option  would be to just
> LIBM=
> case $host in
> *-*-beos* | *-*-cegcc* | *-*-cygwin* | *-*-haiku* | *-*-pw32* | *-*-darwin*)
>   # These system don't have libm, or don't need it
>   ;;
> *)
>   LIBM=-lm
>   ;;
> esac
> AC_SUBST([LIBM])
> i.e. copy&paste libtool AC_CHECK_LIBM without that AC_CHECK_LIB part (and
> without *-ncr-sysv* entry which we don't support in GCC AFAIK), so something
> in between using -lm unconditionally and not using it on targets which don't
> really need it.

yes that seems a better solution - I was about to write:

Seeing your comment #7, I think that the bare metal is a red herring (it just
happened to be the reporter) - actually the issue is the unconditional
GCC_NO_EXECUTABLES, which means that the macro would fail for any build != host
case.

I suppose also that means that build != host == target for mingw or other
targets that do not use '-lm' will also be wrong - so a proper fix is needed
sometime.

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

[iains at gcc dot gnu.org]

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

--- Comment #12 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #10)
> BTW, yet another option  would be to just
> LIBM=
> case $host in
> *-*-beos* | *-*-cegcc* | *-*-cygwin* | *-*-haiku* | *-*-pw32* | *-*-darwin*)
>   # These system don't have libm, or don't need it
>   ;;
> *)
>   LIBM=-lm
>   ;;
> esac
> AC_SUBST([LIBM])

I tested this patch on x86_64-darwin and powerpc64le-linux where it correctly
omits the '-lm' from the libquadmath link line on Darwin, but includes it on
powerpc64le-linux (where it is also currently omitted in an unpatched build).

So, I can also test the patch at comment #2 or we could go with this one.

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I've already started testing the:
2023-12-11  Jakub Jelinek  <jakub@redhat.com>

        PR libquadmath/112963
        * configure.ac (LIBM): Readd AC_CHECK_LIBM-like check without doing
        AC_CHECK_LIB in it.
        * configure: Regenerated.
        * Makefile.in: Regenerated.

--- libquadmath/configure.ac.jj 2023-11-02 07:49:22.120795297 +0100
+++ libquadmath/configure.ac    2023-12-11 19:03:50.823783215 +0100
@@ -122,6 +122,20 @@ esac
 AC_SUBST(toolexecdir)
 AC_SUBST(toolexeclibdir)

+# AC_CHECK_LIBM variant which avoids AC_CHECK_LIB which doesn't work
+# on bare metal.  In the past we've used -lm in Makefile.am unconditionally,
+# let's use it there unless target knows it doesn't need that.
+LIBM=
+case $host in
+*-*-beos* | *-*-cegcc* | *-*-cygwin* | *-*-haiku* | *-*-pw32* | *-*-darwin*)
+  # These system don't have libm, or don't need it
+  ;;
+*)
+  LIBM=-lm
+  ;;
+esac
+AC_SUBST([LIBM])
+
 AC_CHECK_HEADERS(fenv.h langinfo.h locale.h wchar.h wctype.h limits.h ctype.h
printf.h errno.h)
 LIBQUAD_CHECK_MATH_H_SIGNGAM

--- libquadmath/configure.jj    2023-11-02 07:49:22.119795311 +0100
+++ libquadmath/configure       2023-12-11 19:04:04.239598274 +0100
@@ -644,6 +644,7 @@ LIBQUAD_USE_SYMVER_GNU_FALSE
 LIBQUAD_USE_SYMVER_GNU_TRUE
 LIBQUAD_USE_SYMVER_FALSE
 LIBQUAD_USE_SYMVER_TRUE
+LIBM
 toolexeclibdir
 toolexecdir
 MAINT
@@ -10921,7 +10922,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 10924 "configure"
+#line 10925 "configure"
 #include "confdefs.h"

 #if HAVE_DLFCN_H
@@ -11027,7 +11028,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11030 "configure"
+#line 11031 "configure"
 #include "confdefs.h"

 #if HAVE_DLFCN_H
@@ -12260,6 +12261,20 @@ esac



+# AC_CHECK_LIBM variant which avoids AC_CHECK_LIB which doesn't work
+# on bare metal.  In the past we've used -lm in Makefile.am unconditionally,
+# let's use it there unless target knows it doesn't need that.
+LIBM=
+case $host in
+*-*-beos* | *-*-cegcc* | *-*-cygwin* | *-*-haiku* | *-*-pw32* | *-*-darwin*)
+  # These system don't have libm, or don't need it
+  ;;
+*)
+  LIBM=-lm
+  ;;
+esac
+
+
 for ac_header in fenv.h langinfo.h locale.h wchar.h wctype.h limits.h ctype.h
printf.h errno.h
 do :
   as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
--- libquadmath/Makefile.in.jj  2023-11-02 07:49:22.108795464 +0100
+++ libquadmath/Makefile.in     2023-12-11 19:04:57.971857555 +0100
@@ -355,6 +355,7 @@ INSTALL_SCRIPT = @INSTALL_SCRIPT@
 INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
 LD = @LD@
 LDFLAGS = @LDFLAGS@
+LIBM = @LIBM@
 LIBOBJS = @LIBOBJS@
 LIBS = @LIBS@
 LIBTOOL = @LIBTOOL@

version.

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

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

commit r14-6451-gfdce86c9f07eb4f95ba438491c2b151e94be7ef2
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Dec 12 08:57:02 2023 +0100

    libquadmath: Restore linking against -lm on most targets [PR112963]

    The r14-4825 change added AC_CHECK_LIBM to libquadmath configure.ac and
    replaced unconditional linking with -lm with linking with $(LIBM)
    determined by that.
    Unfortunately that broke bare metal targets because AC_CHECK_LIBM attempts
    to link against -lm and this was after (unconditional) GCC_NO_EXECUTABLES.
    Then r14-4863 partially reverted that change (no longer AC_CHECK_LIBM),
    but didn't revert the Makefile.am change of -lm to $(LIBM), which had
    the effect that libquadmath is not linked against -lm on any arch.
    That is a serious problem though e.g. on Linux, because libquadmath calls
    a few libm entrypoints and e.g. on powerpc64le the underlinking can cause
    crashes in IFUNC resolvers of libm.
    Instead of adding further reversion of the r14-4825 commit and use -lm
    unconditionally again, this patch adds an AC_CHECK_LIBM like substitutions
    with the *-ncr-sysv4.3* target handling removed (I think we don't support
    such targets, especially not in libquadmath) and with the default case
    replaced by simple using -lm.  That is something in between using -lm
    unconditionally and what AC_CHECK_LIBM does if it would work on bare metal
    - we know from GCC 13 and earlier that we can link -lm on all targets
    libquadmath is built for, and just white list a couple of targets which
    we know don't have separate -lm and don't want to link against that
    (like Darwin, Cygwin, ...).

    2023-12-12  Jakub Jelinek  <jakub@redhat.com>

            PR libquadmath/112963
            * configure.ac (LIBM): Readd AC_CHECK_LIBM-like check without doing
            AC_CHECK_LIB in it.
            * configure: Regenerated.
            * Makefile.in: Regenerated.

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.