Linking gcc-compiled subroutines and libraries with intel fortran on MacOS

[daldystultz]

I am a recent user of intel FORTRAN on my Mac (MacOS X 10.5.8), and I am about to toss everything out the window. Unlike any other compiler I have used, Intel fortran seems to have all sorts of issues with linking not only gcc-compiled object files, but libraries compiled with ifort!

I compile the main routines of my code with an ifort statement such as:

ifort -c -o zeus3d.o -O2 -diag-disable remark zeus3d.f

There are about 250 such subroutines.

Then I compile my only C-routine with:

gcc -c -ansi checkin.c

Then I try to link with

ifort -o xdzeus36 -O2 zeus3d.o ...(the 250 other .o files compiled by ifort)... checkin.o -L/usr/local/ncarg/ifort/lib -lncarg_gks ...(several other libraries)

and I get messages of the type:

ipo: warning #11009: file format not recognized for checkin.o

ld: warning in checkin.o, file is not of required architecture

ld: warning in /usr/local/ncarg/ifort/lib/libncarg_gks.a, file is not of required architecture

and while these are "only" warnings", they seem to result in a whole slew of "Undefined symbols", which prevents the link.

Questions:

1. What does one have to do with gcc and/or ifort to get ifort to recognise the format of the gcc-compiled file? No other fortran compiler seems to have an issue with gcc-compiled files: f95 (Solaris/AIX), g95, nor gfortran. Only the compiler I had to *pay* for (ifort) has a problem. BTW, I am not a C-programmer at all, though I do know that c-program names seem to require double underscores on some systems, a single underscore on others, and none on yet others. I have tried all three on the Mac, and none seem to make any difference--always unrecognised format.

2. What is "not of required architecture", and how do I get rid of it?

I have never had such a problem linking before as I have had with ifort. I've been compiling and linking fortran with C for 25 years with compilers supported by Cray, Convex, IBM, SUN, Portland, and the gnu suite. Never has one given me the headaches of intel and never have they come with such useless documentation!!

Thanks for any advice anyone can share.

David.

[Ron_Green]

David,

I'm sorry for your frustration. Luckily, it's a pretty easy problem to resolve.

Do you want 32bit or 64bit code? By default, ifort is creating 64bit code. You can use 'file *.o' to confirm this:

ifort -c hello.f90
FordPrefect:~ rwgreen$ file hello.o
hello.o: Mach-O 64-bit object x86_64

whereas gcc is creating 32bit code unless you use -m64:

$ gcc -c second_wall.c
FordPrefect:~ rwgreen$ file second_wall.o
second_wall.o: Mach-O object i386


you can't mix 64bit .o files with 32bit .o files.

SO either use -m64 with gcc OR choose the 32bit ifort compiler with -m32:

$ gcc -c second_wall.c -m64
FordPrefect:~ rwgreen$ file second_wall.o
second_wall.o: Mach-O 64-bit object x86_64

ifort -m32 -c hello.f90
file hello.o
hello.o: Mach-O object i386

ron

[Ron_Green]

One other minor note: if you are compiling Fortran module procedures into static libraries using 'ar', make sure to run 'ranlib' on the .a file before using it in a link. This is another difference with development on Mac OS X.

ron

[daldystultz]

Quoting - Ronald W. Green (Intel)

David,

I'm sorry for your frustration. Luckily, it's a pretty easy problem to resolve.

Do you want 32bit or 64bit code? By default, ifort is creating 64bit code. You can use 'file *.o' to confirm this:

ifort -c hello.f90
FordPrefect:~ rwgreen$ file hello.o
hello.o: Mach-O 64-bit object x86_64

whereas gcc is creating 32bit code unless you use -m64:

$ gcc -c second_wall.c
FordPrefect:~ rwgreen$ file second_wall.o
second_wall.o: Mach-O object i386


you can't mix 64bit .o files with 32bit .o files.

SO either use -m64 with gcc OR choose the 32bit ifort compiler with -m32:

$ gcc -c second_wall.c -m64
FordPrefect:~ rwgreen$ file second_wall.o
second_wall.o: Mach-O 64-bit object x86_64

ifort -m32 -c hello.f90
file hello.o
hello.o: Mach-O object i386

ron

Thank you Ron. Yes, that seemed to do the trick. I wonder where in the reams and reams of documentation a relatively naive user like myself (with lots of experience in scientific computing; just no interest in becoming a Techspert) would have come across this. I'm certainly aware of the 32-bit to 64-bit migration, and have been stung by it in various forms on numerous occasions. But to recognise "not of required architecture" and "file format not recognised" as having to do with 32 vs 64 bit compiling is quite beyond me. Why wouldn't the warning just say: "mismatch between 32 bit and 64 bit compiling; use -m32"? But then I have always lamented about how non-user friendly error/warning messages seem to be!

Thanks again.

David.

[Ron_Green]

Quoting - daldystultz

Thank you Ron. Yes, that seemed to do the trick. I wonder where in the reams and reams of documentation a relatively naive user like myself (with lots of experience in scientific computing; just no interest in becoming a Techspert) would have come across this. I'm certainly aware of the 32-bit to 64-bit migration, and have been stung by it in various forms on numerous occasions. But to recognise "not of required architecture" and "file format not recognised" as having to do with 32 vs 64 bit compiling is quite beyond me. Why wouldn't the warning just say: "mismatch between 32 bit and 64 bit compiling; use -m32"? But then I have always lamented about how non-user friendly error/warning messages seem to be!

Thanks again.

David.

It is a really bad error message and if I didn't have the job I have where I see it frequently I'd have no idea what it meant either. The Intel compiler uses the system linker, gnu ld, for the link phase. This is so that we can be compatible with gnu gcc/g++ and the platform OS (gnu ld on Mac or Linux, on Windows we use the Microsoft linker). We do our best to make sure our .o files are compatible and then rely on the system linker to do the final linkage. So the error message is beyond our control, unfortunately.

Documentation: We do have a section on mixed language programming, but it focuses on the rudimentary topics such as type matching, argument passing, and calling conventions.

One other note is to become familiar with the -mcmodel option. This option is in both gcc and ifort. It specifies the memory model and controls the maximum size of COMMON data. If you need COMMONS greater than 2GB, you'll need -mcmodel medium.