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