Xcode doesn't seem to find Intel Libraries...

[Richard_M_1]

I'm probably doing something enormously stupid, but I'm stumped. I'm new to Xcode and am porting an exisiting Fortran application from Windows to Mac OS X using the Intel Fortran compiler on both. I installed Xcode, moved the code, sorted out the differences between the platforms (mostly getting the DFPORT and IFPORT conditional compilations right) and the compile phase succeeds.

When Xcode trys to link though, it doesn't seem to be finding/using the Intel libraries. I've tried both the dynamic and static settings in the Xcode options. Here's the command to the linker:

Ld "/Users/munroe/Documents/My CVS/ESPlanner_Computation_Engine.HEAD/ESPlanner Executables-Xcode/espbasic/espbasic/build/Debug/espbasic" normal i386
cd "/Users/munroe/Documents/My CVS/ESPlanner_Computation_Engine.HEAD/ESPlanner Executables-Xcode/espbasic/espbasic"
/usr/bin/ifort-10.1-base/bin/ifort -o "/Users/munroe/Documents/My CVS/ESPlanner_Computation_Engine.HEAD/ESPlanner Executables-Xcode/espbasic/espbasic/build/Debug/espbasic" "-L/Users/munroe/Documents/My CVS/ESPlanner_Computation_Engine.HEAD/ESPlanner Executables-Xcode/espbasic/espbasic/build/Debug" -L/opt/intel/fc/10.1.014/lib -L/opt/intel/fce/10.1.014/lib -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/darwin/default "-F/Users/munroe/Documents/My CVS/ESPlanner_Computation_Engine.HEAD/ESPlanner Executables-Xcode/espbasic/espbasic/build/Debug" -filelist "/Users/munroe/Documents/My CVS/ESPlanner_Computation_Engine.HEAD/ESPlanner Executables-Xcode/espbasic/espbasic/build/espbasic.build/Debug/espbasic.build/Objects-normal/i386/espbasic.LinkFileList" -arch i386 -nostdlib -mmacosx-version-min=10.5 -dev-usr-root=/Developer/usr -shared-intel "" "" -Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk

and I get a boatload of linker errors, mostly [I haven't ported a dynamic library we use on the Windows version yet, so those were expected] indicating that a lot of things like _memcpy, _for_* (where * is a bunch of thing related to I/O and other stuff), and _sortqq (and all the other IFPORT things that I use in the code). I've tried adding libifcore.a (or .dynlib as appropriate to the -share/-static-intel switch) to the project and that gets rid of the _for_* errors, but I'm still missing the ifport stuff (sortqq, et al.) and things like the fortran intrinsics (_ciel, _floor). I've tried it with both 64 and 32 bit builds and with both static and dynamic libraries. I've tried adding the libraries manually, but there doesn't seem to be any indicator of which libraries go with which missing reference so that's kind of hit or miss.

So what simple thing am I doing wrong?

Thanks in advance,

Dick Munroe

[Richard_M_1]

p.s. Additioinally, I ported the C++ library as a static BSD library, which is cool. Now I'm having a similar problem trying to get the linker to resolve things like _fclose. I can't figure out how to get the fortran compiler to link against libc (I tried the -cxxlib switch with no joy). I did find the fortran intrisics, their in libimf so that problems resolved. I'm now down to resolving the IFPORT stuff and the c run time (things like fclose, fprintf, etc).

Best,

Dick Munroe

[Richard_M_1]

More information. I was able to resolve the various C run time library errors by dropping libc.dylib into the project. I was able to then resolve the various gxx errors by adding libstdc++.6.dylib into the project. This all seems a bit obscure (and may not work since I actually haven't been able to test the application, I'll probably have to try a test jig). I STILL haven't been able to get the following IFPORT library items to resolve:

"_drand", referenced from:
_grandom in gRandom.o
_grandom in gRandom.o
"_getdati2", referenced from:
_configuration_mp_configurationendcontainer_ in configuration.o
_MAIN__ in Main.o
"_lnblnk", referenced from:
_windows32api_mp_calculateoutputpath in windows32API.o
"_sortqq", referenced from:
_socialsecurity_mp_pia in socialSecurity.o

So progress of a sort, but this still doesn't make a lot of sense and none of this is documented.

Not exactly what I expect from Intel.

[Ron_Green]

Dick,

The Xcode integration of the Intel Fortran compiler is a "preview feature". This means that you will find some anomalies and oddities from what you are used to with IVF on Windows.

And as you noted, we have not created a 'porting code from IVF to Intel Fortran for Mac OS* X' document.

However, what I tend to do for missing symbols is this - I cd to the lib directory for the compiler. Then:

nm | grep | grep "T "

The "T" designates a target in the object library, that is, the actual source you are looking for.

Now for sortqq, you will note that

nm libifport.a | grep sortqq | grep "T "

Or if you don't know which lib it is in:

nm *.a | grep sortqq | grep "T "
libifport.a(f90_sortqq.o):
00000000 T _sortqq_


shows that the actual symbol name is "_sortqq_", the key being the trailing underscore. What is odd is that your code is looking for "_sortqq" with NO underscore.

_drand_ is in libifport.a
as is _getdati2_
and _lnblnk_

So make sure libifport (either .a or .dylib) is part of your link.




I also tried a clean project and successfully added and linked with a call to sortqq:

program hello
use ifport
implicit none
integer(2) array(10)

write(*,*) 'Hello World'

call sortqq(LOC(array), 10, SRT$INTEGER2)

end program hello



If you have libifport in your link, it is possible that a project Build setting is causing the underscore to not be appended to names, that is, '-assume nounderscore' may be getting set by one or more of your project Build properties.

ron

[Richard_M_1]

Thanks, I had forgotten the nm hack.

However, the _sortqq reference was generated by the fortran compiler, not by anything I did. In the fortran code, I have:

USE IFPORT

...

CALL SORTQQ(...)

...

so it looks as if the compiler is generating bogus function calls to IFPORT entrypoints (or the libifport.a has bogus entry point names) or something. Needless to say this code compiles and links on Windoze. Guess I'll have to fire up a support request and see whats going on.

Best,

Dick Munroe

[Ron_Green]

Dick,

Before you enter the support request - where is your "CALL" in front of "CALL SORTQQ(...)"?
You cannot call SORTQQ as a function.

[Richard_M_1]

The undescore on external procedures was the problem. I turned that on, undid a few of my own errors introduced when I was trying to figure out what was going on and I've gotten things to build.

Whew, I knew it couldn't be as hard as I was making it.

Thanks for the help.

Best,

Dick Munroe

[Richard_M_1]

Yeah, I know about the CALL, it's there.

Best,

Dick