Compile error with for_main.o

[Brian_Allison]

I am trying to compile a code that works fine in windows. I am getting this error when it goes to create the executable.

ifort -O0 -g -auto -ansi_alias- -pad_source -traceback -fpconstant -nogen-interfaces \\

relap/relapd.a scdap/scdapd.a \\

matpro/matprod.a scdap/scdapd.a envrl/envrld.a \\

relap5l.dylib -o relap5d.x

Undefined symbols:

"_MAIN__", referenced from:

_main in for_main.o

ld: symbol(s) not found

make[1]: [relap5d.x] Error 1 (ignored)

ifort -O0 -g -auto -ansi_alias- -pad_source -traceback -fpconstant -nogen-interfaces \\ relap/relapd.a scdap/scdapd.a \\ matpro/matprod.a scdap/scdapd.a envrl/envrld.a \\ relap5l.dylib -o relap5d.xUndefined symbols:"_MAIN__", referenced from: _main in for_main.old: symbol(s) not foundmake[1]: [relap5d.x] Error 1 (ignored)

I am running IFC 11.1.084 andI tried IFC 11.1.088

[Ron_Green]

OK, that answers one question: were the symbols simply mangled with decoration - no. The only reference you have is the call or reference to voldat_mp_vol. But you don't have a target anywhere in the libraries.

Now the question is, why aren't the .o files from your modules getting included in the archive? The make script must be hosed. Can you find the source for voldat, find the .mod and .o file created during the make? If you nm voldat.o (or whatever the name of the object containing the voldat module data and procedures) you will find "T _voldat_mp_vol_ ". Then you will have to unravel why the make is not including these .o files into the appropriate .a file with ar r and ranlib -c. You can manually add the .o with ar r and use nm to verify that the target "T" for voldat_mp_vol is added to the library. So why isn't the makefile adding them in?

It's some weird bug in the build script.

ron

[Brian_Allison]

Here is what was in the voldat.o file.

0000000000000744 T _voldat._

Just a note the problems I am having are with Fortran 77 coding. We have another version that has beencompletelyrewritten in Fortran 90/95 standards and it works fine. Would the differences in the code cause these problems?

[Ron_Green]

Brian,

Yes, it makes a big difference (f77 version vs. f90 version): The call, the "U" is expecting the Fortran 90 MODULE version of voldat - the name tells us this, remember:

_voldat_mp_vol_

the "_mp_" tells us the symbol is expected to be a MODULE PROCEDURE. In F77, there were no modules. So as you saw, the symbols are simple without the _mp_ and will not match. Totally different beasts: a module procedure is different than an old F77 EXTERNAL procedure.

So I'll cross my fingers: if you have the F90 versions of this code you'll need to use them. OR you revert EVERYTHING back to the old F77 style. No mixing and matching in this case.

ron

[Brian_Allison]

Here is what we have for versions.

relap5 mod 3.4 Fortran 77

relap5 mod 4 fortran 90/95

Each version is in its own folder. There is no mixing of fortran coding.

[Ron_Green]

what I meant by "mixing" is between the calling code and the called code. The caller in this case is expecting the module (fortran09/95) version of voldat. So the objects in teh Fortran 90/95 should be compiled and added to the libraries.

ron

[mecej4]

It is not quite clear from the exchanges here whether this conjecture is correct, but here goes:

When linking routines contained in a number of object files and libraries, the one that contains _MAIN__ (the number and placement of underscores may vary with the platform) should be in an object file and _not_ in a library (.a or .so type file).

Procedures and other global symbols may be pulled into the a.out either from .o files or .a files. Objects within an archive (static or dynamic) are linked in only to satisfy the need for an unsatisfied external. Explicitly named objects are (usually) linked in, whether or not they are acutally needed, but some linkers are smart enough (or in response to a user request) to leave out objects that are not referenced.

Therefore, if _MAIN__ is a symbol only inside an archive and not one of the explicitly named objects, most (but not all) versions of ld will flag _MAIN__ as "not found".

The original poster may find it useful to read the ld manual pages for his/her platform.

[Brian_Allison]

Well, I removed the ranlib lines in the make file and now I am getting a different error.

ifort -O0 -g -auto -ansi_alias- -pad_source -traceback -fpconstant -nogen-interfaces relap/relap5.obj \

relap/relapd.a scdap/scdapd.a matpro/matprod.a \

envrl/envrld.a relap5l.dylib -o relap5d.x

Undefined symbols:

"_inputd_", referenced from:

_MAIN__ in relap5.obj

"_trnctl_", referenced from:

_MAIN__ in relap5.obj

ld: symbol(s) not found

make[1]: [relap5d.x] Error 1 (ignored)

I am not getting a huge list of undefined symbols now. If I do a nm on the relap5.obj file, the _inputd_ and _trnctl_ has a U in front of it.

[mecej4]

You have reached a point at which you do not need to step down from the Fortran level. It is obvious from the output of ld that

(i) the _MAIN__ IS defined in relap5.obj

and

(ii) relap5.f (or .f90) contains references to subroutines or functions called "inputd" and "trnctl".

All that you need to do is to identify the source files where these two are defined, compile those source files and include the resulting .o files in the link step.

For instance, if you have all your sources in one directory, within that directory you can do

grep -in inputd *.f90

to locate these references.

[Brian_Allison]

Well I got it working. Something was wrong with the make file. I pulled in a make file from another version and now it works fine. Thank you for all of the help anyways.