0

I am currently working on a project involving Fortran and R, but the emphasis lies on the latter and not much coding is needed on the Fortran side. The aim is to create a dynamic library/shared object containing a Fortran subroutine to be loaded into R where it can be called.

Some background:

I have been given a Fortran file which contains a module called FitterModule.f95 and set up my Fortran subroutine in another Fortran file called zyzzyva.f95. The subroutine is to utilise a function (al00) that is within the module itself, and the code is as shown below:

subroutine al00wrapper(ca, d, answer)
    use FitterModule
    real :: ca, d, answer
    answer = al00(ca, d)
    return
end subroutine

After which, I proceeded to Macbook terminal to create the shared library, with the following commands:

gfortran -c zyzzyva.f95
gfortran -shared -o zyzzyva.so zyzzyva.o
gfortran -shared -o zyzzyva.so zyzzyva.o FitterModule.o 
gfortran -shared -o zyzzyva.so FitterModule.o zyzzyva.o

However, each time I was given the following result:

Undefined symbols for architecture x86_64:
  "_al00_", referenced from:
      _al00wrapper_ in zyzzyva.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

I have looked through posts that could have been similar to mine, but I am unable to figure out what is wrong still.

I am definitely very new to this and I appreciate if I could get some advice to resolve this issue, thank you!

Vladimir F Героям слава
  • 57,977
  • 4
  • 76
  • 119
Eden
  • 1
  • 1
  • 1
    Looks like you are missing the reference to the `al00` routine. So either provide this routine when creating the .so or a reference in another so to it. – albert Aug 17 '19 at 09:10
  • Looks like the symbol is missing in one way or the other, can you do a `nm FitterModule.o | grep -i al00` – albert Aug 17 '19 at 12:13
  • Hi @albert, thank you for getting back to me! I have no idea by what you mean in your initial comment on how I can provide this routine when creating the `.so`. Also, I have done `nm FitterModule.o | grep -i al00` and the result I got was: `00000000000038a9 t ___fittermodule_MOD_al00` `U _al00_` `000000000000d87a T _al00wrapper_` Hope this will be useful in troubleshooting the issue! – Eden Aug 17 '19 at 13:14
  • did you do a `nm *.o | grep -i al00` ? Why is `al00wrapper` otherwise in `FitterModule.o`? Interesting is also `nm zyzzyva.o | grep -i al00`. Where did you complie the `FitterModule` ? – albert Aug 17 '19 at 13:19
  • @albert My apologies, I saw your second question and I realised I messed up the code a little while trying to fiddle in order to solve my problem. In fact, `nm FitterModule.o | grep -i al00` now returns `00000000000038a9 t ___fittermodule_MOD_al00`, while `nm *.o | grep -i al00` returns the original result that I obtained. I've tried compiling `FitterModule` on Codeblocks but encountered a fatal error which says that it can't open the module file `FitterModule.mod0` for writing at (1) as there is no such file or directory, hence I compiled it directly in Terminal. – Eden Aug 17 '19 at 13:54
  • Disclaimer I never used a Mac to compile Fortran code. It looks a bit like there is a discrepancy in compiling in Codeblocks and in a terminal window, but the error from Codeblocks is something that should be solved so that you have in Codeblocks a consistent state. A small test could also be to compile everything in a terminal window and see what happens (cleaning first of course the `.o`, `.mod*`, `.so` and maybe other temporary / result files. In case in the terminal window the link does give a problem run `nm *.0 | grep -i al00` for clues. – albert Aug 17 '19 at 14:06
  • @albert Thank you for taking your time to point me in the correct direction on this issue and highlighting something new to me, I greatly appreciate it! Will continue to work on this in the direction that you have mentioned! – Eden Aug 17 '19 at 14:28
  • Use tag [tag:fortran] for all Fortran questions. There is nothing 95 specific in it anyway. Be aware that the f95 suffix is not very portable https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/284757 https://stackoverflow.com/questions/20269076/correct-suffix-for-fortran-2003-source-file-intel-fortran-compiler – Vladimir F Героям слава Aug 17 '19 at 17:05
  • Clearly, the subroutine `a100` is in the module `fittermodule`. When you compile that module gfortran mangles the name by adding `__fittermodule_MOD_` as a prefix. If you want to be able to reference that subroutine by `_a100_`, use ISO BIND C and name the routine accordly. – evets Aug 17 '19 at 17:46
  • I am not sure but you can look into the `Valid Architectures` area. Libraries you are using might not have support for `x86_64` – Naveed Abbas Aug 23 '19 at 12:15

0 Answers0