Potential Problems Between Clang And Gfortran

Recently I have been working on an update of the port french/aster from version 14.4.0-1 to 14.6.0-1, with its dependencies, and it has been committed (r556349).

1st problem:

My first attempt was to keep clang as the C compiler, as everything builds fine. But testing, either as a batch program or via the GUI ASTK, produced seg-faults.

I located the problem: in a FORTRAN subroutine (bibfor/jeveux/jelira.F90), when the program wants to put a value in the return parameter cval (line #312):

This is an output parameter. Previously it has been initialized with 32 spaces by a C function MakeBlankFStr(), called by jeveux_getattr() in bibc/supervis/aster_module.c. This initialization in MakeBlankFStr() / BlankStr() is done by memset(). At this point everything is still OK, and the error arises in the FORTRAN subroutine.

Firstly I suspected a bug caused by memset(3), and replaced it by memset_s: no change.

Then, I tried to replace clang by GCC (9.3.0) to compile the C code of french/aster, and the error disappeared!

2nd problem:

During my 1st attempt to compile french/aster, the linker (called by gfortran) returned an error.

The culprit was a missing reference, available in libTFELSystem.so, installed from the port science/tfel. I do not see any reason why it fails, because the same command works fine when the C code is compiled by clang!

The command line is very long, but for those interested, it is available at https://gist.github.com/thierry-FreeBSD/e7159aeab8a064b6d6ef1fc916c9b9e5.

To solve this error when french/aster is compiled by GCC, science/tfel must be also compiled by GCC. (Actually, since I did not want to modify science/tfel in this way, I repocopied science/tfel to science/tfel-edf)

To resume:

The strange thing is that aster is linked with many other libraries (libpython3.7m, libmed, libhdf5, libdmumps, libmetis, libscotch, etc.), all of them being compiled with clang (if supported by arch), without error: only science/tfel is affected by this issue.

TODO

ATM, just waiting for gfortran10, which should be available RSN, and check if these problems still exist. If they remain, try to build a much smaller test case to reproduce these errors, and report them upstream.


CategoryPorts

PotentialProblemsBetweenClangAndGfortran (last edited 2020-11-29T12:32:26+0000 by MarkLinimon)