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-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 (http://netbsd.org/~bacon/) 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




Home | Main Index | Thread Index | Old Index