Potential Problems Between Clang And Gfortran
Updating the port french/aster let me face to two problems, for which I suspect the interface between clang (10 or 11) and gfortran9 (9.3.0) on FreeBSD.
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):
- cval = cva(1:lcv)
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!
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)
- if both tfel and aster are compiled by clang, the linker is OK;
- if both tfel and aster are compiled by GCC, the linker is OK;
- if tfel is compiled by clang and aster by GCC, it does not link.
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.
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.