Problems with EXAMPLES/MODEL_DRIVERS/ex_model_driver_P_LJ

I'm trying to compile one of the example model drivers on a Mac (OX X 10.8.5, gcc 4.7.2 and make 3.81 from macports). I can compile the api itself (i.e. "make openkim-api"), but when I try a plain make, I get the following:

[bernstei@magnesium openkim-api-v1.4.0]$ make

***************************************************************************=


** Making… kim-api-objects =
**
***************************************************************************=


make[1]: Nothing to be done for `objects’.

***************************************************************************=


** Making… kim-api-libs =
**
***************************************************************************=


make[1]: Nothing to be done for `libs’.

***************************************************************************=


** Making… Model Driver… ex_model_driver_P_LJ =
**
***************************************************************************=


Creating… ex_model_driver_P_LJ.so.
ld: illegal text-relocation to _reinit in ex_model_driver_P_LJ.a(ex_model_d=
river_P_LJ.o) from anon in ex_model_driver_P_LJ.a(ex_model_driver_P_LJ.o) f=
or architecture x86_64
collect2: error: ld returned 1 exit status
make[1]: *** [ex_model_driver_P_LJ.so] Error 1
make: *** [ex_model_driver_P_LJ-all] Error 2

This is the non-default part of my Makefile.KIM_config:

KIM_DIR =3D $(HOME)/src/work/OpenKIM/openkim-api-v1.4.0
#KIM_MODEL_DRIVERS_DIR =3D
#KIM_MODELS_DIR =3D
#KIM_TESTS_DIR =3D

KIM_COMPILERSUITE =3D GCC
KIM_SYSTEMLINKER =3D darwin
KIM_SYSTEMARCH =3D 64bit
KIM_LINK =3D dynamic-load

Any suggestions as to what’s going on with the linking?

Hi Noam,

I've just resolved essentially the same issue for Ron Miller...

See this post

https://groups.google.com/d/msg/openkim/fxAAJeOC5UY/USep96FAu-EJ

Let me know if it doesn't work for you...

Ryan

Hi Noam,

I noticed you mentioned macports. I was using the macports gcc 4.8.2 and it seems to have been compiled using disable-multilib, which doesn’t allow Ryan’s 32bit solution to work. I had to switch to a different gcc 4.8.2. I actually compiled and installed it from src on my machine but there are other options. I think Ryan said that the homebrew gcc package is OK.

After that, though, Ryan’s solution worked for me.

ron

I poked around the some macports threads and discovered that if you install gcc47+universal it does not disable multilib, so I did that. However, it’s now giving a different error, just compiling the API (which worked before):

[bernstei@magnesium openkim-api-v1.4.0] make clean Creating... KIM_Config file..... KIM_API/Makefile.KIM_Config. Creating... KIM_Config file..... MODEL_DRIVERS/Makefile.KIM_Config. Creating... KIM_Config file..... MODELS/Makefile.KIM_Config. Creating... KIM_Config file..... TESTS/Makefile.KIM_Config. Cleaning... Model Driver... ex_model_driver_P_LJ. Cleaning... Model Driver... ex_model_driver_P_LJ. Cleaning... KIM_API. Cleaning... KIM_Config files. [bernstei@magnesium openkim-api-v1.4.0] make openkim-api
Creating… KIM_Config file… KIM_API/Makefile.KIM_Config.
Creating… KIM_Config file… MODEL_DRIVERS/Makefile.KIM_Config.
Creating… KIM_Config file… MODELS/Makefile.KIM_Config.
Creating… KIM_Config file… TESTS/Makefile.KIM_Config.

I just noticed that I had set FCC instead of FC, but oddly, fixing that doesn’t help, despite the fact that manually running gfortran with the right flags works:

[bernstei@magnesium KIM_API] gfortran -m32 -c -fcray-pointer KIM_API_F.F90 [bernstei@magnesium KIM_API]

Is there any way to increase verbosity from the compilation system, so I can see what it’s doing?

Noam

Aah, answered my own question - you have to set the compiler variables later in Makefile.KIM_config. It would be nice if that were documented someplace in the default/example Makefile.KIM_config.

Hi Noam,

The example file has a section heading that says "overwrite default compiler options here"

What else would you suggest?

Thanks,

Ryan

What else would you suggest?

Good question. In my version (1.4.0) it says “# overwrite default variable values here”, which I find less obvious than the text you quoted. Maybe it should have been enough to clue me in, but it apparently wasn’t.

Maybe you can’t do better if the user isn’t paying attention :), but how about something like “# overwrite default compiler options and other variables here”?

One thing that would have helped was if I could have seen the commands that were being executed by make. It took me a while to figure out that the lack of options passed to gfortran was indeed the problem. Any way to enable that?

Noam

OK, that is helpful. I'll make some adjustments there...

Also, If you use

   make -n

it will show you the commands it would have executed. So, you can use this to see what command lines are being used. Unfortunately make doesn't really provide a better way to turn this on and off...

Maybe there is a hack I can use... I'll look into it.

Ryan