Re: math/blas not compiling due to gcc7 error

To: Jason Bacon <outpaddling%yahoo.com@localhost>
Subject: Re: math/blas not compiling due to gcc7 error
From: Connor McLaughlan <cont6pro3%gmail.com@localhost>
Date: Sun, 23 Aug 2020 21:31:08 +0200
On Sun, Aug 23, 2020 at 3:45 PM Jason Bacon <outpaddling%yahoo.com@localhost> wrote:
>
> On 2020-08-23 07:58, Lai, Peter PW wrote:
> >> -----Original Message-----
> >> From: pkgsrc-users-owner%NetBSD.org@localhost [mailto:pkgsrc-users-
> >> owner%NetBSD.org@localhost] On Behalf Of Jason Bacon
> >> Sent: Wednesday, August 19, 2020 10:12 PM
> >> To: Connor McLaughlan <cont6pro3%gmail.com@localhost>
> >> Cc: Juraj Lutter <otis%netbsd.org@localhost>; pkgsrc-users%netbsd.org@localhost
> >> Subject: [External] Re: math/blas not compiling due to gcc7 error
> >>
> >> On 2020-08-19 16:24, Connor McLaughlan wrote:
> >>> On Wed, Aug 19, 2020 at 10:59 PM Connor McLaughlan
> >> <cont6pro3%gmail.com@localhost> wrote:
> >>>> On Wed, Aug 19, 2020 at 2:24 AM Jason Bacon <outpaddling%yahoo.com@localhost>
> >> wrote:
> >>>>> On 2020-08-18 17:26, Connor McLaughlan wrote:
> >>>>>> On Tue, Aug 18, 2020 at 10:56 AM Connor McLaughlan
> >> <cont6pro3%gmail.com@localhost> wrote:
> >>>>>>> On Tue, Aug 18, 2020 at 9:49 AM Juraj Lutter <otis%netbsd.org@localhost>
> >> wrote:
> >>>>>>>>> On 18 Aug 2020, at 09:35, Connor McLaughlan
> >> <cont6pro3%gmail.com@localhost> wrote:
> >>>>>>>>> On Sat, Aug 15, 2020 at 2:11 AM Connor McLaughlan
> >> <cont6pro3%gmail.com@localhost> wrote:
> >>>>>>>>>> I am unsure if this is an error of blas by calling the
> >>>>>>>>>> undefined reference in libgfortran.so or by gcc7 to have
> >>>>>>>>>> experienced an error during building of its fortran compiler.
> >>>>>> So i think there is something wrong with the gcc7 build via pkgsrc on
> >> sparc64.
> >>>>>> The libgfortran.so has undefined symbols of the cab* functions.
> >>>>>> There are patches for gcc7 that have the focus to adjust these
> >>>>>> issues for NetBSD, but something is not working out for gfortran on
> >> sparc64:
> >>>>>> bash-5.0# more patch-gcc_config.gcc
> >>>>>> $NetBSD: patch-gcc_config.gcc,v 1.4 2018/11/09 11:22:13 mrg Exp $
> >>>>>>
> >>>>>> Workaround netbsd's compatibility non-C99 cabs (causes gfortran
> >>>>>> link failures)
> >>>>>>
> >>>>>> bash-5.0# cat patch-gcc_config_netbsd-protos.h [...]
> >>>>>> +#ifndef _NETBSD_PROTOS_H_
> >>>>>> +#define _NETBSD_PROTOS_H_
> >>>>>> +
> >>>>>> +double __c99_cabs (double complex); float __c99_cabsf (float
> >>>>>> +complex); long double __c99_cabsl (long double complex);
> >>>>>> [...]
> >>>>>>
> >>>>>> Should i start a new mailing since this seems not to be a problem of
> >>>>>> math/blas or math/coinmp?
> >>>>>>
> >>>>>> Regards,
> >>>>>> Connor
> >>>>> FYI, can't reproduce the problem on AMD64:
> >>>>>
> >>>>> => Checking file-check results for blas-3.9.0
> >>>>> => Creating binary package
> >>>>> /home/bacon/Pkgsrc/pkgsrc/wip/blas/work/.packages/blas-3.9.0.tgz
> >>>>> ===> Building binary package for blas-3.9.0
> >>>>> => Creating binary package
> >>>>> /home/bacon/Pkgsrc/pkgsrc/packages/All/blas-3.9.0.tgz
> >>>>> ===> Installing binary package of blas-3.9.0
> >>>>> localhost: {21} pwd
> >>>>> /home/bacon/Pkgsrc/pkgsrc/wip/blas
> >>>>> localhost: {22} uname -a
> >>>>> NetBSD localhost 9.0 NetBSD 9.0 (GENERIC) #0: Fri Feb 14 00:06:28 UTC
> >>>>> 2020
> >> mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC
> >>>>> amd64
> >>>>>
> >>>> I have done a little testing on Linux/amd64.
> >>>>
> >>>> Here i compile lang/gcc7 and the gfortran is able to compile
> >>>> math/coinmp, so in theory should be working.
> >>>>
> >>>> But i was again unable to compile math/blas or wip/blas, this time
> >>>> with a different error (which is of no particular importance to me, my
> >>>> sparc64 error is the one i need solved):
> >>>>
> >>>> -- The Fortran compiler identification is GNU 7.5.0
> >>>> -- The C compiler identification is GNU 9.2.1
> >>>> -- Check for working Fortran compiler:
> >>>> /usr/pkgsrc/math/blas/work/.cwrapper/bin/gfortran
> >>>> -- Check for working Fortran compiler:
> >>>> /usr/pkgsrc/math/blas/work/.cwrapper/bin/gfortran - broken
> >>>> CMake Error at /usr/pkg/share/cmake-
> >> 3.17/Modules/CMakeTestFortranCompiler.cmake:45
> >>>> (message):
> >>>>     The Fortran compiler
> >>>>
> >>>>       "/usr/pkgsrc/math/blas/work/.cwrapper/bin/gfortran"
> >>>>
> >>>>     is not able to compile a simple test program.
> >>>>
> >>>>     It fails with the following output:
> >>>>
> >>>>       Change Dir: /usr/pkgsrc/math/blas/work/lapack-
> >> 3.9.0/obj/CMakeFiles/CMakeTmp
> >>>>       Run Build Command(s):/usr/bin/gmake cmTC_7e63b/fast && make  -f
> >>>> CMakeFiles/cmTC_7e63b.dir/build.make
> >> CMakeFiles/cmTC_7e63b.dir/build
> >>>>       Building Fortran object
> >> CMakeFiles/cmTC_7e63b.dir/testFortranCompiler.f.o
> >>>>       /usr/pkgsrc/math/blas/work/.cwrapper/bin/gfortran   -O -c
> >>>> /usr/pkgsrc/math/blas/work/lapack-
> >> 3.9.0/obj/CMakeFiles/CMakeTmp/testFortranCompiler.f
> >>>> -o CMakeFiles/cmTC_7e63b.dir/testFortranCompiler.f.o
> >>>>       Linking Fortran executable cmTC_7e63b
> >>>>       /usr/pkg/bin/cmake -E cmake_link_script
> >>>> CMakeFiles/cmTC_7e63b.dir/link.txt --verbose=1
> >>>>       /usr/pkgsrc/math/blas/work/.cwrapper/bin/gfortran  -L/usr/pkg/lib
> >>>> -Wl,-R/usr/pkg/lib -L/usr/lib64 -Wl,-R/usr/lib64  -O
> >>>> CMakeFiles/cmTC_7e63b.dir/testFortranCompiler.f.o  -o cmTC_7e63b
> >>>>       /usr/bin/ld: cannot find -lgcc_s
> >>>>       collect2: error: ld returned 1 exit status
> >>>>       *** Error code 1
> >>>>
> >>>>       Stop.
> >>>>       make[1]: stopped in
> >>>> /usr/pkgsrc/math/blas/work/lapack-3.9.0/obj/CMakeFiles/CMakeTmp
> >>>>       gmake: *** [Makefile:141: cmTC_7e63b/fast] Error 1
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>     CMake will not be able to correctly generate this project.
> >>>> Call Stack (most recent call first):
> >>>>     CMakeLists.txt:3 (project)
> >>>>
> >>>>
> >>>> -- Configuring incomplete, errors occurred!
> >>>> See also "/usr/pkgsrc/math/blas/work/lapack-
> >> 3.9.0/obj/CMakeFiles/CMakeOutput.log".
> >>>> See also "/usr/pkgsrc/math/blas/work/lapack-
> >> 3.9.0/obj/CMakeFiles/CMakeError.log".
> >>>> *** Error code 1
> >>>>
> >>>> Stop.
> >>>> bmake[1]: stopped in /usr/pkgsrc/math/blas
> >>>> *** Error code 1
> >>>>
> >>>> Stop.
> >>>>
> >>>>
> >>>> Regards,
> >>>> Connor
> >>> Error with fortran compiling on linux/amd64 (opensuse) was solved by a
> >>> soft-link of libgcc_s.so to libgcc_s.so.1 in /lib64
> >>>
> >>> So both math/blas and math/openmp compile on linux/amd64 with a
> >>> freshly built lang/gcc7.
> >>>
> >>> Now back to searching the bug on why the same scenario fails on
> >> NetBSD/sparc64
> >>> Regards,
> >>> Connor
> >> This is a known issue that's solved by forcing the GCC package to build
> >> its own libgcc.
> >>
> >> In addition to that, I also make the GCC packages use pkgsrc binutils on
> >> my CentOS systems, since the CentOS "as" is old and doesn't understand
> >> some opcodes generated by newer GCC versions. The following is added to
> >> mk.conf automatically by auto-pkgsrc-setup
> >> (https://urldefense.com/v3/__http://netbsd.org/*bacon/__;fg!!MvWE!SpX
> >> rB4RF-
> >> nJERBn0Axe6nts920oDF1XEK1Dr9LYGlQW3vG88a0YI3lzZE7Bd9vXqCmQYPg$ )
> >> to avoid these issues:
> >>
> >> .if exists(/etc/redhat-release) && !empty(PKGPATH:Mlang/gcc*)
> >>
> >> # RHEL systems may have an outdated "as" that cannot translate instructions
> >> # from current GCC code generators, so force pkgsrc binutils.
> >> CONFIGURE_ARGS+=        --with-gnu-as --with-as=${PREFIX}/bin/gas
> >> CONFIGURE_ARGS+=        --with-gnu-ld --with-ld=${PREFIX}/bin/gld
> >> BUILDLINK_DEPMETHOD.binutils=   full
> >> .  include "../../devel/binutils/buildlink3.mk"
> >>
> >> # pkgsrc gcc packages don't install libgcc_s on some platforms, to
> >> # avoid problems when mixing compiler versions.  This breaks our use
> >> # of pkgsrc gcc on EL.
> >> PKG_DEFAULT_OPTIONS+=   always-libgcc
> >> .endif  # RHEL
> >> .endif  # BSD_PKG_MK
> >>
> > FYI you can probably avoid all of this on Centos/RHEL (including openSUSE) by installing the redhat developers toolsets software collection which  is basically redhat's in-house attempt at splitting the build toolchain away from redhat-base *and* implement an alternatives system. I had to bootstrap with dev-toolsets because the gcc version that ships with Centos/RHEL 7 is so old that texproc/icu won't build with gcc 4.8.5. For example, devtoolset 7 provides gcc7. Cygwin packages are already built with gcc9 and devtools-9 has been working well for me on native redhat (see also centos.pkgs.org/7/centos-sclo-rh-x86_64/devtoolset-9-9.1-0.el7.x86_64.rpm.html) instead of having to rebuild my toolchain. For openSUSE: see lists.opensuse.org/opensuse-buildservice/2019-01/msg00059.html . On *BSD I'd go with a full pkgsrc/ports build though because those architectures' shipped toolchain are intended for building base and the only other managed-toolchain available is through pkgsrc/ports.
> I'd thought about that, but is the toolset collection ABI stable? The
> system I'm using with pkgsrc gcc has been very reliable for a few years
> now and depends only on GCC and OpenJDK from Yum.  I use pkgsrc for
> everything else, except a few more Yum libs required by commercial
> software.  It's also very easy to bootstrap with auto-pkgsrc-setup.  I'm
> currently using pkgsrc gcc8 and will likely move to 9 before too long.
>

Both packages math/blas and math/coinmp have as a dependency the gcc7
package. So it is built and used and its gfortran part fails.
So i guess gcc7 has to be used; also this all is selected and arranged
automatically by pkgsrc. Don't even know how to change it.

But I have searched a bit more for the problem math/blas reports:

    /usr/pkgsrc/math/blas/work/.cwrapper/bin/gfortran  -L/usr/pkg/lib
-Wl,-R/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib  -O
CMakeFiles/cmTC_5d236.dir/testFortranCompiler.f.o  -o cmTC_5d236
    /usr/bin/ld:
/usr/pkg/gcc7/lib/gcc/sparc64--netbsd/7.5.0/../../../libgfortran.so:
warning: warning: reference to compatibility cabsf()
    /usr/bin/ld:
/usr/pkg/gcc7/lib/gcc/sparc64--netbsd/7.5.0/../../../libgfortran.so:
warning: warning: reference to compatibility cabs()
    /usr/bin/ld:
/usr/pkg/gcc7/lib/gcc/sparc64--netbsd/7.5.0/../../../libgfortran.so:
undefined reference to `cabsl'
    collect2: error: ld returned 1 exit status
    *** Error code 1

bash-5.0# ldd /usr/pkg/gcc7/lib/gcc/sparc64--netbsd/7.5.0/../../../libgfortran.so
/usr/pkg/gcc7/lib/gcc/sparc64--netbsd/7.5.0/../../../libgfortran.so:
        -lm.0 => /usr/lib/libm.so.0
        -lc.12 => /usr/lib/libc.so.12
        -lgcc_s.1 => /usr/lib/libgcc_s.so.1

So /usr/lib/libm is used for math functions.

/usr/lib/libm links to the base system:
lrwxr-xr-x   1 root  wheel       22 Jun 24 17:52 libm.so ->
../../lib/libm.so.0.12
lrwxr-xr-x   1 root  wheel       22 Jun 24 17:52 libm.so.0 ->
../../lib/libm.so.0.12
lrwxr-xr-x   1 root  wheel       22 Jun 24 17:52 libm.so.0.12 ->
../../lib/libm.so.0.12

bash-5.0# nm /lib/libm.so |grep cab
000000000001f300 T __c99_cabs
000000000001f2e0 T __c99_cabsf
000000000001f2c0 T __c99_cabsl
000000000001f340 T cabs
000000000001f320 T cabsf

So it seems the problem is cabsl missing in /lib/lim.so which then is
a problem of the base system?

How can this be fixed?

Regards,
Connor
Follow-Ups:
- Re: math/blas not compiling due to gcc7 error
  - From: Martin Husemann
- Re: math/blas not compiling due to gcc7 error
  - From: Jason Bacon
References:
- Re: math/blas not compiling due to gcc7 error
  - From: Lai, Peter PW
- Re: math/blas not compiling due to gcc7 error
  - From: Jason Bacon
Prev by Date: diff from 2020-08-19 01:24 to 2020-08-21 15:41
Next by Date: Re: Patches for editors/emacs27
Previous by Thread: Re: math/blas not compiling due to gcc7 error
Next by Thread: Re: math/blas not compiling due to gcc7 error
Indexes:
Home | Main Index | Thread Index | Old Index