tech-pkg archive

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

Re: making gfortran work better



On 07/18/18 22:22, coypu%sdf.org@localhost wrote:
if anyone's tried to use their base compiler and pkgsrc gfortran, they
encounter errors like the following (building math/R):

checking how to get verbose linking output from gfortran... -v
checking for Fortran 77 libraries of gfortran...  -L/current/pkgsrc/math/R/work/.buildlink/lib -L/current/pkgsrc/math/R/work/.x11-buildlink/lib -L/usr/pkg/gcc7/lib/gcc/x86_64--netbsd/7.3.0 -L/usr/pkg/gcc7/lib/gcc/x86_64--netbsd/7.3.0/../../../../x86_64--netbsd/lib -L/usr/pkg/gcc7/lib/gcc/x86_64--netbsd/7.3.0/../../.. -Wl,-R/usr/pkg/gcc7//lib/. -Wl,-R/usr/pkg/gcc7/lib/. -lgfortran -lm -lquadmath -lpthread
checking how to get verbose linking output from gcc... -v
checking for C libraries of gcc...  -L/current/pkgsrc/math/R/work/.buildlink/lib -L/current/pkgsrc/math/R/work/.x11-buildlink/lib -lgcc_s -lpthread
checking for dummy main to link with Fortran 77 libraries... none
checking for Fortran 77 name-mangling scheme... lower case, underscore, no extra underscore
checking whether gfortran appends underscores to external names... yes
checking whether gfortran appends extra underscores to external names... no
checking whether mixed C/Fortran code can be run... configure: WARNING: cannot run mixed C/Fortran code
configure: error: Maybe check LDFLAGS for paths to Fortran libraries?


this is because of two problems:
1. configure finds fortran flags (FFLAGS) but only uses C flags to build
mixed code.
2. pkgsrc hides non-whitelisted paths, like the path to libgfortran.so.4

The following diff fixes both problems, although the first only by accident.


Index: gfortran.mk
===================================================================
RCS file: /cvsroot/pkgsrc/mk/compiler/gfortran.mk,v
retrieving revision 1.9
diff -u -r1.9 gfortran.mk
--- gfortran.mk	12 Sep 2016 12:18:13 -0000	1.9
+++ gfortran.mk	19 Jul 2018 03:19:25 -0000
@@ -90,9 +90,8 @@
  PREPEND_PATH+=	${_GFORTRAN_DIR}/bin
  .  endif
-# Add the dependency on gfortran.
-BUILDLINK_DEPMETHOD.gcc${GFORTRAN_VERSION}=	full
-.  include "../../lang/gcc${GFORTRAN_VERSION}/buildlink3.mk"
+# Resulting package will need the fortran libraries.
+.  include "../../lang/gcc${GFORTRAN_VERSION}-libs/buildlink3.mk"
. if defined(GFORTRAN_DIR) && !empty(GFORTRAN_DIR)
  PKGSRC_MAKE_ENV+=	GFORTRAN_DIR=${GFORTRAN_DIR:Q}


having gcc7-libs, means I whitelist the paths to the libraries, and also we
inject a specfile to them to all compilers, so it solves problem #1, so
even the C compiler knows where libgfortran.so.4 is.

ok to commit this?

p.s. I can probably do similar to split out gcc7-libgfortran without
libgcc_s and libstdc++.
What platform(s) have you tested this on?

It seems like a good idea, but I tend to be paranoid about such far-reaching changes, as I've seen some very surprising
consequences of seemingly innocuous mods many times in the past.

Specifically, I depend heavily on use of C, C++, and Fortran all from the same gcc package on CentOS.  I don't see any danger from this change, but the fact that I don't see something doesn't mean it's not there.

I would just like to see thorough testing on a variety of platforms before committing something like this. I can contribute
to the effort.


Home | Main Index | Thread Index | Old Index