Compile error with for_main.o

Compile error with for_main.o

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.xUndefined symbols:"_MAIN__", referenced from: _main in for_main.old: symbol(s) not foundmake[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

30 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Is the main program in Fortran or in another language? If in another language, add -nofor-main

Retired 12/31/2016

I fixed the for_main.o error and now I am getting this error:
ifort -logoIntel Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build 20100203 Package ID: m_cprof_p_11.1.084Copyright (C) 1985-2010 Intel Corporation. All rights reserved. if [ ! -d "d" ]; then mkdir "d"; fils envrl/*.hh >filedothls envrl/*.ff >filedotfls matpro/*.hh >filedothls matpro/*.ff >filedotfls relap/*.hh >filedothls relap/*.ff >filedotfls scdap/*.hh >filedothls scdap/*.ff >filedotfauxx/builderm.x makermacpcd ..make -f makrelap NM=d FFLAGS="-O0 -g" FPSTOP= \ O=obj cpl=ifort -O0 -g -auto -ansi_alias- -pad_source -traceback -fpconstant -nogen-interfaces -nofor-main \ 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 libifcore.a(for_main.o)ld: symbol(s) not foundmake[1]: [relap5d.x] Error 1 (ignored)

That looks like the same error. Where is your main program? Is it Fortran or is it in one of those libraries?

Retired 12/31/2016

This was the error before I added the -nofor-main.Undefined symbols:Undefined symbols:"_MAIN__", referenced from: _main in for_main.old: symbol(s) not foundThis is the error I am getting now.Undefined symbols:ndefined symbols:"_MAIN__", referenced from: _main in libifcore.a(for_main.o)ld: symbol(s) not foundThey are different. The main program is fortran.

Actually, I think they are the same. Either you transcribed them wrong or your display was garbled. If the main program is in Fortran, then do not use -nofor-main. In which object is the main program? What do you get with a "nm -a" on that object?

Retired 12/31/2016

If I don't use the -nofor-main I get the error about the for_main.o file, if I use the -nofor-main then I get the error about thelibifcore.a(for_main.o).I did not transcribe anything wrong. I cut and pasted the text from my look files. As far as the "main" program it is in my fortran files. What do you mean by nm -a on the object?

The errors are the same, but there are characters missing or garbled from the first one - at least in the reply a couple back.

I mean do:

nm -a mainprog.o

where mainprog.o is the object from compiling your main program. This will list the global symbols defined and used by that object.

Retired 12/31/2016

Here is what I got from the main program.0000000000000000 T _MAIN__00000000000afc90 C _alcm_0000000000001410 C _balfar_0000000000019920 C _bconds_0000000000000790 C _bcons_0000000000002b30 C _bder_ U _blkdat_ U _blkdt2_ U _blkdta_0000000000001fd0 C _bln2wk_00000000000007b0 C _bloona_0000000000000150 C _bloonb_000000000000a090 C _bloond_0000000000000810 C _bsize_0000000000001e20 C _buntim_0000000000000070 C _bwcons_0000000000017cd0 C _bwgeom_0000000000019070 C _bwprop_000000000002fc10 C _bwtrns_000000000001e510 C _cdfinc_0000000000001fa0 C _cdfinv_0000000000000050 C _cmatp_0000000000000020 C _cmptim_0000000000000860 C _comctl_0000000000000050 C _cons_0000000000000310 C _contrl_0000000000000290 C _coupl_0000000000000020 C _cpmdat_00000000000000b0 C _cprdat_00000000000c31d0 C _dbacct_0000000000012c10 C _debout_0000000000006490 C _effprp_0000000000000040 C _eht0_0000000000000040 C _ehtc0_000000000002a150 C _farays_0000000001e84800 C _fast_00000000000065c0 C _fecom_0000000000000040 C _fginvc_0000000000022410 C _fgrcom_ U _for_set_reentrancy U _for_stop_core0000000000001b90 C _fpbin_00000000000021b0 C _fpcoef_00000000000000b0 C _fpctrl_0000000000000060 C _fpinsc_0000000000000b10 C _fpinsh_0000000000014050 C _fpmass_0000000000000050 C _fpmdl_0000000000007810 C _fpnonv_0000000000000100 C _fpvol_00000000000000d0 C _ftb_0000000000000010 C _ftbfet_00000000000000b0 C _genrl_0000000000086650 C _grscgr_0000000000000350 C _grsprg_0000000000001020 C _hardpn_0000000000000050 C _hfuson_ U _incond_ U _inputd_0000000000041bd0 C _intcom_0000000000000320 C _iparm_00000000000001d0 C _k3all_0000000000000300 C _k3point_0000000000000030 C _lvel_00000000000009c0 C _madatc_0000000000001c20 C _matdat_0000000000000020 C _matsrs_0000000000000010 C _maxmem_0000000000002c40 C _miscon_0000000000000070 C _mxnfbv_0000000000000e70 C _mxnfcv_0000000000000020 C _nbtim_0000000000001e90 C _ndxara_0000000000011250 C _nhtara_0000000000041cb0 C _nrcom_00000000000000a0 C _oxcom1_0000000000000020 C _oxcom2_0000000000000020 C _oxcom3_0000000000000350 C _parg_00000000000001c0 C _parm_0000000000001490 C _plndat_0000000000000100 C _prdat_0000000000005cf0 C _ptscom_0000000000011850 C _radata_0000000000000330 C _rgacct_00000000000004b0 C _rmadac_0000000000000390 C _rupt_00000000000d12b0 C _scdcom_0000000000000010 C _scddat_000000000003c9c0 C _scdout_00000000000016e0 C _scdpow_0000000000000040 C _scntl_0000000000019a50 C _slbcom_0000000000007940 C _slumpv_0000000000000040 C _solcom_0000000000000240 C _statec_0000000000000010 C _stcblk_0000000000000030 C _std2xc_0000000000000030 C _sth2xc_ U _strip_00000000002239d0 C _tblsp_0000000000000150 C _thplot_ U _trnctl_0000000000006e90 C _trnot1_000000000000f090 C _trnot2_0000000000000f00 C _ufilef_0000000000000030 C _ufiles_0000000000021c20 C _uoxcom_0000000000000030 C _vel_00000000000c3500 C _virtul_

Ok. That tells me that _MAIN__ is defined in this object. Now, which file, named in your ifort command that does the linking, is this object?

Retired 12/31/2016

# Explicit Targetsrelap5$(NM).x: envrl/envrl$(NM).a matpro/matpro$(NM).a \ relap/relap5.$O relap/relap$(NM).a scdap/scdap$(NM).a \ tpfh2o$(NM) tpfd2o$(NM) relap5l.dylib $(f90) $(FFLAGS) $(FPSTOP) $(FL) -nofor-main \ relap/relap$(NM).a scdap/scdap$(NM).a \ matpro/matpro$(NM).a scdap/scdap$(NM).a envrl/envrl$(NM).a \ relap5l.dylib -o relap5$(NM).xThe relap/relap$(NM).a contains the main object deck. THe line relap/relap5.$O is the Main object or program.

Take out -nofor-main.

I think I need a Linux expert to comment on this...

Retired 12/31/2016

With the -nofor-main removed, I get a complaint about undefined symbols referenced from for_main.o.

Brian,

I am confused, please help me. First, let's ignore the fact that this compiled on Windows. What we need to know is: Is the main program in C or Fortran? In C, I would expect

void main() {
..etc..
}

In Fortran:
PROGRAM Foo
...stuff..
end

OR for really old F77 code:
...stuff...
end

The linker is telling us that you don't have either a C or a Fortran main program. If C, -nofor-main should be used. If Fortran you don't need the option but you do need to provide the source file or object file that contains the PROGRAM.

thanks

ron

It is in Fortran. No C anywhere in our code. So, I will remove the -nofor-main line. I placed the object in IFORT line and I am getting all kinds of undefined symbols now.Here is the IFORT lineifort -O0 -g -auto -ansi_alias- -pad_source -traceback -fpconstant -nogen-interfaces \ relap/relapd.a scdap/scdapd.a matpro/matprod.a \ envrl/envrld.a relap/relap5.obj relap5l.dylib -o relap5d.xThe bold underline is the main program. The main program is also included in the relapd.a library found in the bold italic underlined. I think that is where the conflict is.

You are right: you should not put a main program in a static library, relapd.a. That is certain to cause problems. Get it out of there. If the main program is in relap5.obj that is OK, but it can't exist in 2 places and it should never be in a static or dynamic library.

ron

ok, so I pulled it out of the library and re-compiled. I am still getting undefined symbols.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.xUndefined symbols:"_jundat_mp_njunsj_", referenced from: _imlp_ in relapd.a(imlp.obj) _imlp_ in relapd.a(imlp.obj)"_voldat_mp_volclear_", referenced from: _gninit_ in relapd.a(gninit.obj)"_voldat_mp_vol_", referenced from: _imlp_ in relapd.a(imlp.obj) _imlp_ in relapd.a(imlp.obj) _imlp_ in relapd.a(imlp.obj)...... and so on.

looks like we're making some progress. Let me help to unravel the symbol names and maybe that can help you find the missing symbols or code:

"_valdat_mp_volclear_"

This symbol and the others with similar names are comprised of:

_mp_

So, there is somewhere in your code: MODULE VOLDAT
and in that module is a subroutine or function or data named VOLCLEAR.

When you compile the source for VOLDAT, you get a .mod file which is used to define the interface for VOLDAT and you get a .o file with the actual code (this is greatly simplified but hopefully helpful).

Now, in relapd there is a subroutine or function named GNINIT. It probably has

USE VOLDAT

SO - when you link, you need to add the .o file that you got when you compiled the source with VOLDAT or add that .o to one of your .a files already in the compile/link command

ron

Do you think that I may need to adjust my archiving?
matpro/matpro$(NM).a: $(OBJSM) ar r matpro/matpro$(NM).a $? ranlib -c matpro/matpro$(NM).arelap/relap$(NM).a: $(OBJSR) ar r relap/relap$(NM).a $? ranlib -c relap/relap$(NM).ascdap/scdap$(NM).a: $(OBJSS) ar r scdap/scdap$(NM).a $? ranlib -c scdap/scdap$(NM).aThe undefined symbols error is happening for everything in my .a files.

the archive and ranlib look fine for Mac OS.

Let's try to find our friend valdat_mp_volclear. Try this:

nm */*.a | grep -i valdat_mp_volclear

this will find all occurences of valdat_mp_volclear in your libraries. If you know what library that should be, you could simplify to:

nm relap/relap5.a | grep -i valdat_mp_volclear

What we want to see: We want to find all undefined references flagged with "U " in the nm output. Ideally we want to find 1 place where it is a target (or defined). nm flags these as "T " in the output. For module data, we expect nm to flag those as "C ".

nm foo.a

foo.a(module_foo.o):
0000000000000402 s EH_frame0
0000000000000402 s L_fde_cie_0
00000000000000d4 d STRLITPACK_0
00000000000000c4 d STRLITPACK_1.0.3
00000000000000cc d STRLITPACK_2.0.3
00000000000000b6 T _foo._
00000000000004a2 S _foo._.eh
0000000000000190 C _foo_mp_myarray_ <<< this is real :: my array(100) in the module
0000000000000000 T _foo_mp_rfunc_ <<< this is a module procedure 'rfunc'
000000000000041a S _foo_mp_rfunc_.eh
000000000000001c T _foo_mp_sub1_ <<< is is subroutine "sub1"
0000000000000452 S _foo_mp_sub1_.eh

What we want to look for is valdat_mp_volclear in your libraries, as either "T " or "C ". And once it's found, whether it's upper or lower case, and whether it has leading and trailing underscores.

If we find that one symbol defined, maybe we can figure out what is going on. IF you cannot find it as "T" or "C" but only as undefined "U", then we need to figure out why the .o file from the module containing valdat_mp_volclear is not getting included into the library.

ron

Here is what I found.U _voldat_mp_vol_

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

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?

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

Here is what we have for versions.relap5 mod 3.4 Fortran 77relap5 mod 4 fortran 90/95Each version is in its own folder. There is no mixing of fortran coding.

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

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.

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.xUndefined symbols:"_inputd_", referenced from: _MAIN__ in relap5.obj"_trnctl_", referenced from: _MAIN__ in relap5.objld: symbol(s) not foundmake[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.

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.

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.

Leave a Comment

Please sign in to add a comment. Not a member? Join today