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



Home | Main Index | Thread Index | Old Index