compiling ccx_2.20 under macosx using gcc/gfortran I have encountered this strange message. At first with the three functions v_betrag, v_prod, v_result, which I could heal by defining suitable prototypes in Calculix.h.
This results in the same error message for a function which is generated by the FORTRAN macro. Maybe the same procedure is possible. But imho there should be a general solution as the problem seems to be compiler related. I have tried to change the standard in the makefile, e.g. “-std=c89” and some other options. Upto now no success.
Maybe somebody knows what I am doing wrong or where I am too blind to see.
The 3 modules v_betrag, v_prod, v_result isn’t used in the current ccx_2.20 version so you should remove these 3 modules from the Makefile.inc which should solve your problem.
It is certainly always a good idea to remove unused modules. I shall do that. But in that case I had been successful by providing the prototypes in Calculix.h - thus they are not annoying me anymore.
But alas, your first hint does not help. The error remains. The function in question is generated by the FORTRAN macro in Calculix.h: It appends to the function name an underscore. Then it is called (with that underscore) in a C-procedure. Therefore it is the C compiler which is complaining. From this reason I hoped for a useable standard. Compiling ccx 2.16 never showed such a behaviour.
@hpp
I don’t know the configuration in your makefile, but if you have problem with leading underscore, then you can try to use the c define -DARCH=“Linux”
or you can try to use the c compiler flag -fno-leading-underscore or maybe both.
@fgr Oh, sorry, I have been unprecise. It’s not a leading underscore, but a trailing. Ok, maybe there’s a chance to change the FORTRAN macro to generating a leading underscore? I am not sure, and I don’t like too many interventions in Guido’s structure. I am afraid of side effects.
Btw, the makefile is generally unchanged, the sole exceptions being “CC=gcc” and “FC=gfortran”. DARCH=“Linux” is default …
What I am searching for is the difference between my compiling of ccx_2.16 (which did work, as I have a binary ccx_2.16, running perfectly on my mac) and ccx_2.20. The makefiles look identical. When I try to make ccx_2.16 now (!), I get the same error, i.e. compiling is not possible anymore, although it had been so. There must be a change in the behaviour of the compiler/loader/linker. Maybe updates? I still do not understand.
Question to the whole forum: Is there anyone who had succeeded in making ccx_2.20 for macOS?
I did, just follow the instructions here except for the part of gfortran, current version of gfortran works. My makefile (only spooles, 1 thread, intel processor):
looks like the link failed, you have it in Dhondt’s site: http://www.dhondt.de/INST_CCX_2_8_MAC_02_10_2015.pdf as I said you have to follow the instructions here except for gfortran since current version works as well
Thanks again. I have used this documentation before making ccx_2.16. It had been very helpful back then. But for now? It seems to remain compiler related.
well, as I said I have compiled ccx v2.20 spooles 1 thread in macOS 10.13.6 using gfortran installed with gcc 11.3.0 from Homebrew. No need to modify source files.
@JuanP74 I am able to report some progress. The problem with “clonesensitivities_” is eliminated. I have commented it out in “feasibledirection.c”. It’s obviously not needed.
In massless.c, line 275, the int declaration in the loop has to be removed.
There are additional issues in the source files. In premortar.c, sensi_coor.c and sensi_orien.c the header <string.h> must be included.
All object files are generated, libraries are built!
Missing: pthread (very likely a mac issue). Work to be done.
ccx_2.20 for macOS (catalina) ist done and running!
The last problem has been the library path. Obviously the recent compiler/loader versions cannot find dylibs (which libpthread, libm and libc are) with the standard prefix -l. I have simply inserted the explicit location of these libs, i.e. /usr/lib/lib*.dylib.