Linking errors with ifort compiler

[Manfredo_d_1]

 am trying to build a model written in F90. I keep having problems with it in the linking phase with ifort complaining about undefined symbols. Here are the errors after the compilation which works fine

ifort -o /Users/manfredo/Desktop/ED2/ED/build/ed_2.1-opt edmain.o -I/usr/local/hdf5_mio/include/Users/manfredo/Desktop/ED2/ED/build/ed_2.1-opt.a -lm -lz -L/usr/local/hdf5_mio/lib -lhdf5 -lhdf5_fortran -lhdf5_hl
ifort version 14.0.4
ld: warning: path '/dev/null' following -L not a directory
Undefined symbols for architecture x86_64:
  "_decomp_coms_mp_cwd_frac_", referenced from:
      _init_decomp_params_ in ed_2.1-opt.a(ed_params.o)
      _update_polygon_derived_props_ in ed_2.1-opt.a(update_derived_props.o)
  "_decomp_coms_mp_decay_rate_fsc_", referenced from:
      _init_decomp_params_ in ed_2.1-opt.a(ed_params.o)
      _read_ed_xml_config_ in ed_2.1-opt.a(ed_xml_config.o)

another bunch of similar errors

ld: symbol(s) not found for architecture x86_64
make[1]: *** [/Users/manfredo/Desktop/ED2/ED/build//ed_2.1-opt] Error 1
make: *** [all] Error 2

When looking at the source files these errors kind of make sense because most of the subroutines are declared without explicit interfaces, that is without a  module and a corresponding use statement.

The problem is that the package encompasses hundreds of files and going through all of them to change the interfaces is not feasible. Moreover the same package can be built on other platforms/compilers.

Thus my question is, is it possible to give the compiler options that enable the correct linking even if most of the subroutines don't have explicit interface. Thanks for help

[mecej4]

Manfredo d. wrote:

When looking at the source files these errors kind of make sense because most of the subroutines are declared without explicit interfaces, that is without a  module and a corresponding use statement.

Wrong diagnosis, I think. If implicit interfaces are sufficient, the lack of explicit interfaces will not lead to errors, certainly not linker errors.

You have a malformed LD_LIBRARY_PATH, as the "/dev/null after -L" part of the error message  indicates, and/or you are asking the linker to combine 32 and 64 bit objects and libraries. Probably, one or more of your HDF libraries are 32-bit and you are building a 64-bit target.

[Manfredo_d_1]

I don't see why the HDF libraries should have been built 32-bit but it might be. 

In fact it is weird because the symbols that are not recognized are found in the archive  ed_2.1-opt.a as I have checked with a ar t.

Others symbols in the archive are well managed but some are not.

Do you have any advice for that?

[mecej4]

You did not say which OS you used, but the ar utility is often willing to combine 32 and 64 bit objects into the same *.a file. It acts somewhat like a sleepy file manager, and is too willing to put anything into the *.a file. In fact, I just tried on Cygwin-64, and I find that its version of ar is happy to put a 32-bit object, a 64-bit object and even a Fortran source file into the library! Of course, the poor linker is going to choke when it attempts to use the library.

If the name decoration (adding underscores, changing case, etc.) scheme on your OS is different for 32-bit and 64-bit objects, you can use that information, or, failing that, disassemble a few of the objects in the library to detect their bitness.

[Manfredo_d_1]

I don't really know what is going on, what I can say is that by manually linking the object files I finally succeeded with the compilation. Apparently, albeit certain .o files are appended to the archive they aren't properly recognized. My OS is Mac 10.9 (Mavericks); if you have a diagnosis for this weird error let me know, just for the sake of curiosity.