Thanks @opoplawski. Hi @joa-quim, perhaps you should fix this? I suggest just having

struct MAG_PARAM {
   double rim[3]
};

in okbfuns.h and then add

struct MAG_PARAM * okabe_mag_param = NULL; in the C codes and then allocate/assign there as needed (same where okabe_mag_var is needed).

Not that simple. I need okabe_mag_param and okabe_mag_var to be global in okbfuns.c

Well, then figure about a way to avoid global by passing pointers to functions. Globals are bad news.

I've been trying to do that but old convoluted code. The problem is exactly the pointers to functions. See grdgravmag3d.c #L1201-1203. If I pass the above vars via args then the functions signature is no longer equal.

OK, I will have a look later if I have time. Bloody busy the next week though.

Looks like there is only one exported function in okbfuns.c called okabe that needs to take two more arguments and that is how you pass in okabe_mag_var and okabe_mag_param allocated in the main into okabe which then needs to pass those pointers into functions it calls, such as okb_mag and okb_grv.

Yes, that would be easy but you haven't looked at my grdgravmag3d reference above

	double (*d_func[3])(struct GMT_CTRL *, double, double, double, double, bool, struct BODY_DESC, struct BODY_VERTS *,
	        unsigned int, unsigned int, struct LOC_OR *);

	/* IDEALY THIS SHOULD BE A MUTEX. BUT FIRST: HOW? AND SECOND, WOULDN'T IT BREAK THE WHOLE TREADING MECHANICS? */
...
	v_func[0] = grdgravmag3d_body_set_tri;
	v_func[1] = grdgravmag3d_body_set_prism;
	v_func[2] = grdgravmag3d_body_set_prism;
	d_func[0] = okabe;
	d_func[1] = mprism;
	d_func[2] = bhatta;

The problem is that the functions mprism and batha functions would get different signatures and hence the *d_func[3] array could no longer be used.

Well, I think you just add those two args to all those functions and they are just not used in some of them. That way they have the same # and type of args.

and change all the places where those functions are called ad add dumb args. Not nice either.

Maybe @seisman knows how to have cmake pass -fcommon to the compiler for this supplement.

Changing CMAKE_C_FLAGS should work, but don't have to make it for only one supplement.

I worry about adding -fcommon to all, but perhaps no big deal since if I read @opoplawski correctly the default used to be -fcommon. Perhaps the solution for now is to add -fcommon to the CMAKE_C_FLAGS while we in the mean time try to eliminate the nasty duplication.

We can certainly add -fcommon in the Fedora package as well. I just wanted to get this on your radar so that it does get fixed at some point.

@opoplawski #2511 has landed in master. Could you please test if it builds fine now?

It does, thanks!

Just checking that it passes with -fno-common?

It builds fine with gcc 10, so I would say yes.