topic -assume nounderscore is in Intel® Fortran Compiler

Trying to link gcc and ifort

Clark__Blake — Tue, 09 Apr 2019 23:44:09 GMT

I am trying to compile a complex ocean model with many dependencies and I need to link a set of c and fortran libraries that are being compiled with gcc. From my understanding, the issue stems from ifort (and mpifort compiled with ifort) is looking for the libraries to have an underscore appended on both ends of the library name. The issue is that gcc is compiling the libraries with only one underscore preappended to the front of the object name. I have attempted to use -assume nounderscore compiler option, which works for these libraries but all the other dependencies (e.g. mpich, netcdf) then dont work. I can't post all the code because it is too much, but I will give a sample output from listing the name of the c objects created using gcc, and also the error upon compilation of the code.

dates.o:

U _FORT_Init

00000000000006f0 T _Jul_DUTCofJDN

0000000000000000 T _Jul_DUTCofYMD

0000000000000100 t _Jul_FixYM

0000000000000300 t _Jul_GregYMDofJDN

00000000000005a0 T _Jul_Gregorian

0000000000000610 T _Jul_IsLeapYear

0000000000000710 T _Jul_JDNofDUTC

0000000000000180 t _Jul_JDNofGregYMD

0000000000000220 t _Jul_JDNofJulYMD

0000000000000420 t _Jul_JulYMDofJDN

00000000000006a0 T _Jul_MonthDays

0000000000000530 T _Jul_YDofDUTC

0000000000000290 T _Jul_YMDofDUTC

0000000000000660 T _Jul_YearDays

00000000000008d0 T _fjul_dutcofjdn

0000000000000730 T _fjul_dutcofymd

00000000000007f0 T _fjul_gregorian

0000000000000830 T _fjul_isleapyear

0000000000000900 T _fjul_jdnofdutc

00000000000008a0 T _fjul_monthdays

00000000000007b0 T _fjul_ydofdutc

0000000000000870 T _fjul_yeardays

0000000000000770 T _fjul_ymdofdutc

000000000000092c d _gregorian_day

0000000000000930 d _gregorian_dutc

0000000000000928 d _gregorian_month

0000000000000924 d _gregorian_year

Undefined symbols for architecture x86_64:

"_fjul_dutcoftai_", referenced from:

_mod_time_mp_write_datetime_ in mod_time.o

"_fjul_formatpds_", referenced from:

_mod_time_mp_write_datetime_ in mod_time.o

"_fjul_mjdoftai_", referenced from:

_mod_time_mp_read_datetime_ in mod_time.o

"_fjul_parsedt_", referenced from:

_mod_time_mp_read_datetime_ in mod_time.o

"_fjul_parsetime_", referenced from:

_mod_time_mp_read_time_ in mod_time.o

"_fjul_taiofdutc_", referenced from:

_mod_time_mp_read_datetime_ in mod_time.o

"_fjul_taiofmjd_", referenced from:

_mod_time_mp_write_datetime_ in mod_time.o

This is always a difficult

Juergen_R_R — Wed, 10 Apr 2019 19:49:50 GMT

This is always a difficult business. It works out of the box if code is written in the correct way, namely using bind(C). Otherwise use the same Fortran compiler for all of the Fortran code.

The trailing underscore is a

Steve_Lionel — Wed, 10 Apr 2019 20:03:29 GMT

The trailing underscore is a Linux/UNIX convention for Fortran routine decoration. If you're calling C routines, you're best off to declare them with BIND(C) as Juergen recommends. Don't try mixing ifort and gfortran code.

Where does this BIND(C) go

Clark__Blake — Fri, 12 Apr 2019 13:49:55 GMT

Where does this BIND(C) go within the code/makefile?

As it stands now, I am able to compile the test fortran program that calls the library using the -assume nounderscore option for ifort, and I have installed a trial version of icc to test if I can make it work without that option. It still gives the same error when trying to link the test program and the library. So compiling with icc and ifort still gives the same error as gcc and ifort. Below is the error message and the build script

here is the error message:

Undefined symbols for architecture x86_64:

"_fjul_etoftai_", referenced from:

_MAIN__ in ifortmBWvGW.o

"_fjul_jdoftai_", referenced from:

_MAIN__ in ifortmBWvGW.o

"_fjul_mjdoftai_", referenced from:

_MAIN__ in ifortmBWvGW.o

"_fjul_taiofdutc_", referenced from:

_MAIN__ in ifortmBWvGW.o

"_gjul_formatdate_", referenced from:

_fjul_formatdate_ in libjulian.a(fjulian.o)

"_gjul_formatpds_", referenced from:

_fjul_formatpds_ in libjulian.a(fjulian.o)

"_gjul_formatsql_", referenced from:

_fjul_formatsql_ in libjulian.a(fjulian.o)

"_gjul_formattime_", referenced from:

_fjul_formattime_ in libjulian.a(fjulian.o)

"_gjul_initleaps_", referenced from:

_fjul_initleaps_ in libjulian.a(fjulian.o)

"_gjul_parsedate_", referenced from:

_fjul_parsedate_ in libjulian.a(fjulian.o)

"_gjul_parsedt_", referenced from:

_fjul_parsedt_ in libjulian.a(fjulian.o)

"_gjul_parsetime_", referenced from:

_fjul_parsetime_ in libjulian.a(fjulian.o)

ld: symbol(s) not found for architecture x86_64

and this is the contents of the script used to build it.

icc -c \
dates.c \
format.c \
juldates.c \
leapsecs.c \
parse.c \
seconds.c \
tai_et.c \
utc_tai.c -c
ifort -c fjulian.for

icc -c fortran.c rlerrors.c rlmemory.c
ifort -c fstrings.for

ar crv libjulian.a \
dates.o \
format.o \
juldates.o \
leapsecs.o \
parse.o \
seconds.o \
tai_et.o \
utc_tai.o \
fjulian.o \
fortran.o \
rlerrors.o \
rlmemory.o \
fstrings.o \

ranlib libjulian.a

#rm *.o
ifort -o tconvert tconvert.for libjulian.a

-assume nounderscore is

Steve_Lionel — Fri, 12 Apr 2019 14:30:49 GMT

-assume nounderscore is probably the best bet for now. Adding interface blocks with BIND(C) is a lot more work, and may create other issues if some of the interfaces aren't "interoperable".

I should also add that I was

Clark__Blake — Fri, 12 Apr 2019 15:03:45 GMT

I should also add that I was able to get this to compile completely on a Linux machine with Intel mpiifort and mpicc.

I am having the issues on a MacOS using mpich that was built with the most recent versions of icc and ifort.

The issue is I can get the julian libraries successfully built with -assume nounderscore, but when I try and compile the main ocean model code it gives the same, previous error. Furthermore, if I use -assume no underscore for the main code, then it gives errors for tons of other functions related to mpi and netcdf.

Which previous error?

Steve_Lionel — Fri, 12 Apr 2019 17:21:30 GMT

Which previous error?

All the various sources need to be built so that they agree on name decoration. A lot of C libraries intended for use with Fortran have conditional code to adjust for how particular Fortran compilers do the decoration.