pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: math/blas not compiling due to gcc7 error

On 2020-08-23 14:31, Connor McLaughlan wrote:
On Sun, Aug 23, 2020 at 3:45 PM Jason Bacon <> wrote:
On 2020-08-23 07:58, Lai, Peter PW wrote:
-----Original Message-----
From: [mailto:pkgsrc-users-] On Behalf Of Jason Bacon
Sent: Wednesday, August 19, 2020 10:12 PM
To: Connor McLaughlan <>
Cc: Juraj Lutter <>;
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
<> wrote:
On Wed, Aug 19, 2020 at 2:24 AM Jason Bacon <>
On 2020-08-18 17:26, Connor McLaughlan wrote:
On Tue, Aug 18, 2020 at 10:56 AM Connor McLaughlan
<> wrote:
On Tue, Aug 18, 2020 at 9:49 AM Juraj Lutter <>
On 18 Aug 2020, at 09:35, Connor McLaughlan
<> wrote:
On Sat, Aug 15, 2020 at 2:11 AM Connor McLaughlan
<> wrote:
I am unsure if this is an error of blas by calling the
undefined reference in 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
The 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
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?

FYI, can't reproduce the problem on AMD64:

=> Checking file-check results for blas-3.9.0
=> Creating binary package
===> Building binary package for blas-3.9.0
=> Creating binary package
===> Installing binary package of blas-3.9.0
localhost: {21} pwd
localhost: {22} uname -a
NetBSD localhost 9.0 NetBSD 9.0 (GENERIC) #0: Fri Feb 14 00:06:28 UTC

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:
-- Check for working Fortran compiler:
/usr/pkgsrc/math/blas/work/.cwrapper/bin/gfortran - broken
CMake Error at /usr/pkg/share/cmake-
     The Fortran compiler


     is not able to compile a simple test program.

     It fails with the following output:

       Change Dir: /usr/pkgsrc/math/blas/work/lapack-
       Run Build Command(s):/usr/bin/gmake cmTC_7e63b/fast && make  -f
       Building Fortran object
       /usr/pkgsrc/math/blas/work/.cwrapper/bin/gfortran   -O -c
-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

       make[1]: stopped in
       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-
See also "/usr/pkgsrc/math/blas/work/lapack-
*** Error code 1

bmake[1]: stopped in /usr/pkgsrc/math/blas
*** Error code 1


Error with fortran compiling on linux/amd64 (opensuse) was solved by a
soft-link of to 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
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
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/"

# 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 instead of having to rebuild my toolchain. For openSUSE: see . 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.

gcc7 is the default, but you can set GFORTRAN_VERSION.  Have a look at mk/compiler/ and mk/compiler/

You could also try PKGSRC_FORTRAN=g95 in a pinch, though I have no idea whether it's still supported.

Home | Main Index | Thread Index | Old Index