#language en ## ## This template is for "Port/category/portname" pages. ## ## TODO: Improve the description! #pragma description Wiki page of a port included in the FreeBSD Ports Collection. ## ## TODO: Add more keywords! #pragma keywords FreeBSD, port ## ## Use "----" to separate "==" headers, "-----" to separate "===" and so on. ## Uncomment if you'd like to add a navigation bar for subpages. ## <<Navigation(children)>> ## TODO: Set a correct name here. = 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.'' ## Uncomment to add a table of contents. ## <<TableOfContents()>> Recently I have been working on an update of the port [[https://www.freshports.org/french/aster/|french/aster]] from version 14.4.0-1 to 14.6.0-1, with its dependencies, and it has been committed ([[https://svnweb.freebsd.org/ports?view=revision&revision=556349|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): 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! == 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 [[https://www.freshports.org/science/tfel/|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 [[https://www.freshports.org/science/tfel-edf/|science/tfel-edf]]) To resume: * 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. == TODO == ATM, just waiting for gfortran10, which [[https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246700|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