Problem when compiling the code with FreePGI (macosx)

Accelerated Computing HPC Compilers Legacy PGI Compilers
1

I’m encountering a problem when compiling a fortran code (on macosx mavericks).
During the compilation I got the error:

Undefined symbols for architecture x86_64:
“_commons_clust$0”, referenced from:
lightning in rams-7.0-dbg.a(light.o)
cluster in rams-7.0-dbg.a(cluster.o)
.Lfcmp1 in rams-7.0-dbg.a(cluster.o)
.Lfcmp2 in rams-7.0-dbg.a(cluster.o)
.Lfcmp3 in rams-7.0-dbg.a(cluster.o)
.Lfcmp4 in rams-7.0-dbg.a(cluster.o)
hk in rams-7.0-dbg.a(hk.o)
…
“_commons_lpi$0”, referenced from:
lightning in rams-7.0-dbg.a(light.o)
ave_lpi in rams-7.0-dbg.a(ave_lpi.o)
calcola_lpi in rams-7.0-dbg.a(lpi.o)
leggi_light in rams-7.0-dbg.a(leggi_light.o)
write_out in rams-7.0-dbg.a(write.o)
“_conv_coms$0”, referenced from:
conpar in rams-7.0-dbg.a(rconv.o)
cu_environ in rams-7.0-dbg.a(rconv.o)
kuocp in rams-7.0-dbg.a(rconv.o)
cp2mod in rams-7.0-dbg.a(rconv.o)
“_io_params$0”, referenced from:
comm_time in rams-7.0-dbg.a(rams_master.o)
rams_output in rams-7.0-dbg.a(rams_master.o)
anal_write in rams-7.0-dbg.a(anal_write.o)
anlavg in rams-7.0-dbg.a(ranlavg.o)
.Lfcmp1 in rams-7.0-dbg.a(ranlavg.o)
dtset in rams-7.0-dbg.a(modsched.o)
eng_params in rams-7.0-dbg.a(ruser.o)
…
“_io_params$1”, referenced from:
anal_write in rams-7.0-dbg.a(anal_write.o)
make_sfcfiles in rams-7.0-dbg.a(mksfc_driver.o)
masterput_nl in rams-7.0-dbg.a(mpass_init.o)
nodeget_nl in rams-7.0-dbg.a(mpass_init.o)
ndvi_read in rams-7.0-dbg.a(ndvi_read.o)
ndvi_file_inv in rams-7.0-dbg.a(ndvi_read.o)
ndvi_update in rams-7.0-dbg.a(ndvi_read.o)
…
“_isan_coms$0”, referenced from:
isan_driver in rams-7.0-dbg.a(asgen.o)
opspec4 in rams-7.0-dbg.a(asgen.o)
isan_file_inv in rams-7.0-dbg.a(file_inv.o)
isenio in rams-7.0-dbg.a(isan_io.o)
sigzio in rams-7.0-dbg.a(isan_io.o)
isnstage in rams-7.0-dbg.a(asti.o)
strmfun in rams-7.0-dbg.a(asti.o)
…
“_isan_coms$1”, referenced from:
isan_driver in rams-7.0-dbg.a(asgen.o)
isan_file_inv in rams-7.0-dbg.a(file_inv.o)
isnstage in rams-7.0-dbg.a(asti.o)
strmfun in rams-7.0-dbg.a(asti.o)
isnsig in rams-7.0-dbg.a(avarf.o)
vshyd in rams-7.0-dbg.a(avarf.o)
nvfillm in rams-7.0-dbg.a(rname.o)
…
“_micphys$0”, referenced from:
initlz in rams-7.0-dbg.a(rdint.o)
micro_master in rams-7.0-dbg.a(mic_init.o)
initqin in rams-7.0-dbg.a(mic_init.o)
initqin3 in rams-7.0-dbg.a(mic_init.o)
jnmbinit in rams-7.0-dbg.a(mic_init.o)
micinit in rams-7.0-dbg.a(mic_init.o)
masterput_nl in rams-7.0-dbg.a(mpass_init.o)
…
“_micphys$1”, referenced from:
micro_master in rams-7.0-dbg.a(mic_init.o)
nvfillm in rams-7.0-dbg.a(rname.o)
nameout in rams-7.0-dbg.a(rname.o)
“_node_mod$0”, referenced from:
rams_node in rams-7.0-dbg.a(rnode.o)
init_params in rams-7.0-dbg.a(rnode.o)
init_fields in rams-7.0-dbg.a(rnode.o)
node_index in rams-7.0-dbg.a(rnode.o)
newgrid in rams-7.0-dbg.a(rams_grid.o)
node_sendcyclic in rams-7.0-dbg.a(mpass_cyclic.o)
node_getcyclic in rams-7.0-dbg.a(mpass_cyclic.o)
…
“_rconst_nudge$0”, referenced from:
datassim in rams-7.0-dbg.a(nud_analysis.o)
nudge in rams-7.0-dbg.a(nud_analysis.o)
nudge_no_wind in rams-7.0-dbg.a(nud_analysis.o)
.Lfcmp4 in rams-7.0-dbg.a(nud_analysis.o)
nvfillm in rams-7.0-dbg.a(rname.o)
“_rconst_nudge$1”, referenced from:
nudge in rams-7.0-dbg.a(nud_analysis.o)
nudge_out in rams-7.0-dbg.a(nud_analysis.o)
nudge_out_sfc in rams-7.0-dbg.a(nud_analysis.o)
check_cytime in rams-7.0-dbg.a(nud_analysis.o)
nvfillm in rams-7.0-dbg.a(rname.o)
varf_update in rams-7.0-dbg.a(varf_update.o)
“_ref_sounding$0”, referenced from:
dtset in rams-7.0-dbg.a(modsched.o)
masterput_misc in rams-7.0-dbg.a(mpass_init.o)
nodeget_misc in rams-7.0-dbg.a(mpass_init.o)
optlib in rams-7.0-dbg.a(rprnt.o)
prtopt in rams-7.0-dbg.a(rprnt.o)
uwc in rams-7.0-dbg.a(rprnt.o)
rayf in rams-7.0-dbg.a(rbnd.o)
…
“_rpara$0”, referenced from:
rams_master in rams-7.0-dbg.a(rams_master.o)
master_sendinit in rams-7.0-dbg.a(mpass_full.o)
master_getall in rams-7.0-dbg.a(mpass_full.o)
master_getanl in rams-7.0-dbg.a(mpass_full.o)
masterput_processid in rams-7.0-dbg.a(mpass_init.o)
masterput_nl in rams-7.0-dbg.a(mpass_init.o)
masterput_gridinit in rams-7.0-dbg.a(mpass_init.o)
…
“_rrad3$0”, referenced from:
radiate in rams-7.0-dbg.a(rad_driv.o)
radcalc3 in rams-7.0-dbg.a(rad_driv.o)
mclatchy in rams-7.0-dbg.a(rad_mclat.o)

The above errors refer to fortran modules.
The same code is correctly compiled by gfortran and portland fortran version 10.6.

Thanks.

Stefano

2

Hi Stefano,

Without seeing the code or a snippet that reproduces the problem, I can only offer vague suggestions to help you solve the problem you are seeing. I did a little Google search based on some of the symbols you posted below, and it looks like this could be the RAMS atmospheric modeling code? Possibly from here:

http://bridge.atmet.org/users/software.php

The linker produces these messages when it is attempting to link an executable, and it is unable to resolve certain symbols referenced in the object files that were compiled prior to the link stage.

There are a couple of possible reasons for this:

  1. You forgot to link in a library that defines these symbols. Given that you mentioned that this code works with GNU Fortran, this seems unlikely.

  2. It is possible that the symbols are present in the objects you compiled, but the name mangling is incorrect for some reason. If you mix C and Fortran code together, the C and Fortran symbols have to be defined in a consistent way so that they will link together. The PGI compiler, by default, appends a trailing underscore to every Fortran symbol. So, for example, if you define a Fortran function called CALC_X, PGI will generate the definition of this function as calc_x_. (Basically, everything is converted to lowercase, as Fortran is not case-sensitive, and a trailing underscore is appended.) C code that wants to make a call to this Fortran routine must call it as calc_x_().

  3. There is some other problem causing the symbols to be generated with incorrect names.

Note that the scheme used by PGI in #2 is not a defined standard (though very common), and different compilers may have different conventions for producing Fortran symbols. This makes it a real challenge to write portable Fortran code across a wide variety of compilers, although this problem has been mitigated with the ISO_C_BINDING feature of Fortran 2003.

My advice would be to run the ‘nm’ command on the object files that you are trying to link, and check to see if any symbols closely match the ones you are missing. Here is an example of how to run nm on a binary executable, and the output you would expect to see:

cparrott@mavericks2 $ nm tclsh8.5
0000000100002058 S _NXArgc
0000000100002060 S _NXArgv
00000001000019f0 T _Tcl_AppInit
                 U _Tcl_Init
                 U _Tcl_Main
                 U _Tcl_SetVar2
0000000100002070 S ___progname
0000000100000000 T __mh_execute_header
0000000100002068 S _environ
                 U _exit
00000001000019dc T _main
0000000100002000 s _pvars
                 U dyld_stub_binder
00000001000019a0 T start

If you find symbols that match the ones you are missing, then the next step would be to check the code for any definitions that might change how the symbols are being generated. It is possible there might be a #ifdef or something else that causes different Fortran symbol conventions to be generated.

Lastly, if you could confirm that this is the RAMS code, available from the link above, I would be happy to try it here with FreePGI. Let me know what options you used to compile it.

Hope this helps.

Best regards,

+chris

3

looks like it could be a linker problem

or
you have something wrong with underscores

-fno_second_underscore or similar

4

Hi Chris,

yes, I was compiling the rams model from http://bridge.atmet.org/users/software.php

However, this problem occurs in general, at least on my desktop computer (MBPRO). Now let consider a simple case. I have two separate programs p1.f90 and prova_module.f90. Here are the files:

p1.f90

module p1
real i1,i2,i3
end module p1

\

prova_module.f90

program somma_real
use p1

i1=10.5
i2=10.5
i3=i1+i2

print*,‘The sum of ‘,i1,’ and’,i2,’ is ',i3
stop
end

\

now I compile the programs with FreePGI. The command sequence is:

$pgf90 -c p1.f90
$pgf90 -c prova_module.f90
$pgf90 p1.o prova_module.o

and I got the executable.

Now a different procedure…
The command sequence is:
$pgf90 -c p1.f90
$pgf90 -c prova_module.f90
$ar -r libp1.a p1.o
$pgf90 prova_module.o libp1.a (or $pgf90 prova_module.o -L./ -lp1)

and I got the following error:
Undefined symbols for architecture x86_64:
“_p1$0”, referenced from:
MAIN in prova_module.o
ld: symbol(s) not found for inferred architecture x86_64

and the executable is not created.

Of course, on the same machine, the executable was created by pgf90 (version 10.5).

Regards and many thanks.

Stefano[/b]

5

Hello Stefano,

We have a flyspray related to the issue (fs#20077). It is scheduled to be fixed in 14.7.

In the meantime, one of the workarounds is to initialize the module variables. The other workaround you already know – link with the module object.

Thank you,
Hongyon