Re: math/blas not compiling due to gcc7 error

["Lai, Peter PW" <peter.lai2%prattwhitney.com@localhost>]

> -----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.