Problems compiling a code that works fine on Windows and Linux

[Brian_Allison]

I have a code that we have been compiling for years on LInux and Windows. Just got a Mac and I am trying to compile it using IFC 11.1.084. I am getting an error that we do not understand.

ifort -02 -auto -ansi_alias- -pad_source -warn -traceback -fltconsistency -fpconstant

-nogen-interfaces relap/relap5.o \\

relap/relapo.a scdap/scdap.a contmn/contmn.a \\

matpro/matpro.a scdap/scdap.a envrl/envrl.a \\

-Vaxlib -o relap5o.x

ipo: warning #11015 Warning unknown option -no_compact_unwind

Undefined symbols:

"_zrech2_mp_wh2s", referenced from:

_recomb_ in contemo.a(recomb.o)

_recomb_ in contemo.a(recomb.o)

_recomb_ in contemo.a(vaenph.o)

_recomb_ in contemo.a(vaenps.o)

And the list goes on and on. Not sure what to do. Am i missing an option for compiling on a mac?

[TimP]

Maybe start by dropping some obsolete or undocumented options to see if they cause a problem.

[Brian_Allison]

Are youreferringto the -no_compact_unwind option? We are not using that option and we are not using ipo option (interprocedural optimization). All the options in the ifort command are usable on the mac IFC.

[TimP]

The ipo probably comes as a result of the link script checking by default for any IPO files, so that isn't directly the fault of any options, except as a result of undefined reference.
Vaxlib is a very old option, pad_source isn't documented, fltconsistency isn't documented in the latest compiler (not Mac) which I have.
fltconsistency resembled the current option '-fp-model source'.
ansi-alias is a C option, it should be the default (but isn't documented) for ifort.

[Ron_Green]

you did not say how you built the .a libraries. Make sure to use -O2 and NOT use -fast or -ipo. You did rebuild these on the Mac and are not trying to use libraries built on Linux or Windows, right?

[Brian_Allison]

We are using the command AR to build the libraries. What we have found in that if we manually load the object decks, rather than using a library(the name of the library was left in the load statement), the program loaded and would execute.

I have attached the look file.

[Ron_Green]

On Mac OS X you need to run 'ranlib' on the libraries after you create them. This is unique to Mac OS X. after the ar, add a rule to 'ranlib mylib.a' where you replace mylib.a with your library name.

the -no_compact_unwind is a warning only, and was introduced by the Mac OS X linker ld which changed in 10.6.2. This ld option is being sent to our ifort driver which CURRENTLY doesn't recognize this option. There is a fix in the works for this. The bug number on this is DPD200089706 and you should see it in the next compiler update.

For now, work around it with compiler option -Wl,-no_compact_unwind -wd,11015

which will surpress the warning message.

ron

[Brian_Allison]

I added the ranlib line as specified. Still having same problems.

Here is how the make file looks.

ar -rsv envrl/envrl$(NM).a $?

ranlib envrl/envrl$(NM).a

[Ron_Green]

OK, let's look at one missing symbol:

Undefined symbols:

"_zrech2_mp_wh2s",

decoding this: there is a module named 'zrech2'. inside this module is a symbol, either a subroutine or function or data variable named 'wh2s'. "_mp_" is a generic inserted part of the name for "module procedure". What is odd, by default ifort should be adding a trailing underscore - I would have expected a symbol named _zrech2_mp_wh2s_ UNLESS you have compiled with -assume nounderscore or you have a !DEC$ ALIAS directive to change the way the name is exported. BUT inside procedure recomb, there are calls or uses of it that are referencing the name WITHOUT underscore. Why?

So, 2 things to check:
1) How is the symbol created for wh2s: find where wh2s is declared inside module zrech2. That module is part of a source file. You compile/make to create a .o object file, let's call it 'target.o' just for an example. Use command 'nm' to look for that symbol in target .o:

nm target.o | grep -i wh2s

Now, does wh2s have the Target "T " attribute AND does it have a trailing underscore, like _zrech2_mp_wh2s_

2) find file recomb.o. Use nm to confirm that the reference to _zrech2_mp_wh2s is in there. It should have the "U " attribute, meaning it's a remote/external reference.

"_zrech2_mp_wh2s", referenced from:

_recomb_ in contemo.a(recomb.o)

Now, figure out how recomb.o is built/made. Is there any options used like -assume nounderscore or -nus?

IF you can't find module zrech2 somewhere in your source tree then you are missing source files or a library. Otherwise, figure out why the reference inside recomb.o/contemo.a is removing the underscore.


ron

[Brian_Allison]

I preformed the command: nm zrech2.obj | grep -i wh2s

and got:

0000000000000010 C _zrech2_mp_wh2s_

I did the same thing for the recomb.obj file and got

U _zrech2_mp_ipzs_

U _zrech2_mp_itrh_

U _zrech2_mp_ndrh_

U _zrech2_mp_qrh2_

U _zrech2_mp_ttrh_

U _zrech2_mp_wgae_

U _zrech2_mp_wgas_

U _zrech2_mp_wh2e_

U _zrech2_mp_wh2s_

U _zrech2_mp_wn2e_

U _zrech2_mp_wn2s_

U _zrech2_mp_wo2e_

U _zrech2_mp_wo2s_

U _zrech2_mp_wvpe_

U _zrech2_mp_wvps_

-assume is not used anywhere

[Ron_Green]

The nm output for zrech2.obj shows wh2s and "C" or Common symbol, typically for uninitialized data. Is it safe to assume that wh2s is module data - can you show the declaration of wh2s in module zrech2?

We have seen some issues with "C" data in the past. What version of Mac OS X are you using? And what version of the linker, ld?

$ ld -v
@(#)PROGRAM:ld PROJECT:ld64-95.2.12

Finally, ld is supplied as part of the Xcode tools. What version is your Xcode?

I'm a bit baffled as to why your initial post showed missing symbol "_zrech2_mp_wh2s" without the underscore. I see that the object containing the variable AND the calling routines are referring to the underscored version (correctly so).

ron

[Brian_Allison]

I am running Mac OS X 10.6.2 and XCode 3.2.1

ld version:

@(#)PROGRAM:ld PROJECT:ld64-95.2.12

[Brian_Allison]

I am running Mac OS X 10.6.2 and XCode 3.2.1

ld version:@(#)PROGRAM:ld PROJECT:ld64-95.2.12

One other thing is, I told the make file to manually load all object decks. When I did that, theexecutablewas createdsuccessfully. There is a problem with loading the libraries.

[Brian_Allison]

I removed several of the options and I still had the same problem.

[Ron_Green]

Brian,

At this point I cannot help any further without the code. Would it be possible to 'make clean' and tar up the entire application, makefile(s), and input files? You can attach to this forum using this technique:

http://software.intel.com/en-us/articles/how-to-attach-file-insert-code-into-forum-post/

and I can make this thread private so only you and I can see it (let me know to do this and confirm that it's private if this is how you want to work).

ron

[Brian_Allison]

Have you had a chance to look at the attachment yet?

[Ron_Green]

yes, I am working on it today.

I've simplified the compile options and ar and ranlib options but still no luck. It is odd, I can see the missing symbols inside the .a libraries! ar, ld, ranlib, to me, operate oddly on Mac OS. As you say, we'd be done on linux.

I will keep investigating.

ron

[Ron_Green · Accepted solution]

OK, the key is to simplify the ar and ranlib lines, PARTICULARLY ranlib:

ar r blah blah blah
ranlib -c blah blah blah
^ there's the key. This is different than on Linux:

-c Include common symbols as definitions with respect to the table of contents. This is seldom the intended
behavior for linking from a library, as it forces the linking of a library member just because it uses an
uninitialized global that is undefined at that point in the linking. This option is included only because
this was the original behavior of ranlib. This option is not the default.

Linux ar does this automatically, Mac OS ar/ranlib does not. Common symbols are all of your module data - no wonder there were so many undefined symbols.

I found 1 or 2 of your 'ar' commands in your make* files that did not have a ranlib following them still. Check for those.

your options to ifort could be cleaned up, but it's probably not critical. You have some really ancient compiler options, and some I've never seen ( -ansi_auto for example ). I would recommend these:

-O2 -auto -no-ansi-alias -pad-source -traceback -fpmodel precise -fpconstant

and any -warn options you may want.

ron

[Brian_Allison]

Thank you sooooo much for the help. What you suggested worked.