Updating GCC_DEFAULT from GCC 10 to GCC 11 is blocked by the fact that building this port with GCC 11 gives the following error (full log in URL): !!! build failure encountered !!! 10482,1 Fon 1288 | 'Avector 2', Model % Materials(k) % Values, Pn, Element % NodeIndexes ) | 2 ...... 1452 | DO i=1,MIN(3,SIZE(Hwrk,1)) | 1 Error: Index variable 'i' redefined at (1) in procedure 'inputvector' called from within DO loop at (2) *** [fem/src/modules/CMakeFiles/DCRComplexSolve.dir/DCRComplexSolve.F90.o] Error code 1 Also, please check that USE_GCC is still needed and that the default clang compier can't be used instead.
Created attachment 233549 [details] science_elmerfem_9.0_2.diff This bug was fixed on the devel branch almost a year ago, but it seems better to stay on a well-defined official release for now. The attached patch adds the missing local variable declarations. I have also adjusted the Makefile to keep portclippy and poudriere happy. There is no USE_GCC in this port. Fortran ports use gcc by default because flang only works for the amd64 architecture.
Comment on attachment 233549 [details] science_elmerfem_9.0_2.diff ^Triage: Please set the maintainer-approval attachment flag (to +) on patches for ports you maintain to signify approval Attachment -> Details -> maintainer-approval [+]
Thanks for your patch, I am soon going to commit it.
Thank you, Henrik! (And Salvadore for reporting, testing, and committing. You probably want to make this Approved by: ... (maintainer), gerald (mentor).)
I am sorry, but this is taking longer than I expected: I am having some technical issues testing the patch (issues not related to the patch). Hopefully I will solve them soon. I have not forgotten about your work Henrik, don't worry. By the way, I noticed you put twice science/hdf5 in LIB_DEPENDS. I don't see duplicate dependencies usually in ports, so I am unsure this is is needed. Is there any special reason for this? Thanks.
There is another thing I am unsure: the port tests for GCC_DEFAULT. This has not been introduced by Henrik with his patch, but by Gerald who submitted the patch in the following commit: https://cgit.freebsd.org/ports/commit/science/elmerfem/Makefile?id=f86c964117b6a3ebf2cbf7bb69821dfb8a74f1c2 Gerald, are you sure this is the proper way for testing the compiler? I don't think it is: if I compiled the ports with "make USE_GCC=9" on a system with GCC_DEFAULT=10 I would still get "FFLAGS+= -fallow-argument-mismatch". While I see no reason to specify GCC 9 on the command line, we have however better ways to test for compilers, see https://docs.freebsd.org/en/books/porters-handbook/uses/#uses-compiler Moreover, if the port will ever become compiler agnostic, that line would still affect the port when clang is used. Maintainance is made harder by the fact that gcc dependency is derived from USES=fortran. I would try to replace that test with .if ${CHOSEN_COMPILER_TYPE} == gcc && ${COMPILER_VERSION} >= 10 What do you think about it? Shall I make that change?
(In reply to Lorenzo Salvadore from comment #5) Nah, the second science/hdf5 dependency is just me mechanically copying suggestions from the stage-qa complaints. Everything seems to work well without that line, so feel free to remove it.
Thanks Henrik for your feedback. I completed the tests: everything seems to work fine on amd64 architecture. On the other hand, it seems the port would not build on an i386 system because then sysutils/slurm-wlm is introduced in the dependency tree, but it is marked NOT_FOR_ARCH=i386 (and other archs). So I could not test that elmerfem builds successfully on that architecture. You might want to investigate if slurm-wlm dependency can be removed some way or, in case it is impossible to build elmerferm without it, it might then be a good idea to set NOT_FOR_ARCH=i386 (and other archs) for elmerferm too. Gerald, I just checked my own idea about testing GCC version differently and it does not work: on my system according to 'make -V' CHOSEN_COMPILER_TYPE is clang and COMPILER_VERSION is 130, so we get no information about GCC. Then, unless you have a better idea, I guess we should keep your original solution.
I forgot to write that the investigations about NOT_ARCH are not necessary now for this patch: if anything needs indeed to be done about it, we can deal with that another time with another patch, take your time.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=76eabb91bc3b4876351856d1f156d8611e6a4178 commit 76eabb91bc3b4876351856d1f156d8611e6a4178 Author: Henrik Gulbrandsen <henrik@gulbra.net> AuthorDate: 2022-05-05 00:46:53 +0000 Commit: Lorenzo Salvadore <salvadore@FreeBSD.org> CommitDate: 2022-05-06 13:01:10 +0000 science/elmerfem: Fix build with GCC 11 PR: 263539 Reported by: exp-run (antoine@) Approved by: gerald (mentor) science/elmerfem/Makefile | 6 ++- ...patch-fem_src_modules_DCRComplexSolve.F90 (new) | 58 ++++++++++++++++++++++ 2 files changed, 62 insertions(+), 2 deletions(-)
Commited, thanks again Henrik.