10-30-2009 11:33 AM
I'm trying to compile a Mac version of our lib for a customer that wants to include it in a Photoshop plugin, and he is having trouble linking our lib into his app. More detailed info: His plugin is built against the CS4 Photoshop SDK, which means the Mac OS base SDK should be 10.4. My lib is a static one, compiled with the Intel compiler 11.1 and the base SDK is also set as 10.4.
I tested my lib against a small test app I wrote, and it compiles and works fine (on 10.5). To replicate my customer's environment, the app is compiled with gcc, and uses the 10.4 base SDK. While its fine for me, my customer cannot manage to link with my lib. The problem is the following:
When I compile my lib with gcc,and all other project settings the same, its fine, he can generate an executable. As soon as I compile with ICL, it breaks down. Could it be that ICL 11.1 is not compatible with 10.4? On the Fortran compiler forum, I found the following answer:"From the output provided it appears Xcode defaulted to Mac OS X 10.4, which the 11.1 compilers do not support." (http://software.intel.com/en-us/forums/showthread.php?t=68647)
Does that mean ICL 11.1 does not run on 10.4, or that the code it generates doesn't work on 10.4??
On the following page (http://software.intel.com/en-us/articles/performance-tools-for-software-developers-compatibility-of-intel-compiler-for-mac-os-x-and-xcode/), it also says that ICL 11.1 is not compatible with 10.4 (again same question: what does compatibility mean?). However, it says that ICL 10.1 is, so I tried. But now, even my own test app does not link, for the same reason (undefined function$UNIX2003).
Does anybody know what is the problem, and how to fix it? Or a way to work around it?
Thanks in advance,
10-30-2009 11:45 AM
Also, if somebody knows what that means, please let me know:
ld: absolute addressing (perhaps -mdynamic-no-pic) used in _Cholesky from libMyLib.a(Cholesky.o) not allowed in slidable image. Use '-read_only_relocs suppress' to enable text relocs
10-30-2009 01:24 PM
Try compiling bothyour lib and the small app with the 10.1 compiler.
As for the supported Xcode/OS/icc table. It means those are the combination that the compiler were tested against and verified to work. If it is not listed, thatcould mean several things: not able to run, not able to integrate with Xcode, incompatible with changes in the OS/Xcode dev tools, orin this case, it also means that you can't run the binary generated.
When you build with Intel Compiler, several compiler runtime libraries are linked in to the binary. If you check the symbols in the compiler runtime librariesunder /opt/intel/Compiler/11.1/067/lib, you will find $UNIX2003 symbols. If you check in the 10.1 compiler, the runtime libraries there will not have the $UNIX2003 symbols.
10-30-2009 01:49 PM
Many thanks for the quick answer.
First, I cant compile both of them with ICL, as my customer uses gcc. Hence it has to work with gcc.
Second, when I do a grep fputs$UNIX2003 on the lib/ directory of 10.1, lots of binaries return matches. Actually just the same as with 11.1. What 10.1 do you have? I have 10.1.024.
10-30-2009 02:40 PM
>>> First, I cant compile both of them with ICL, as my customer uses gcc. Hence it has to work with gcc.
Sorry about that, misread and missed that point. You should only need to recompile your library.
>>> Second, when I do a grep fputs$UNIX2003 on the lib/ directory of 10.1, lots of binaries return matches. Actually just the same as with 11.1. What 10.1 do you have? I have 10.1.024.
That is strange... you should not be see that in 10.1.024.
I just installed 10.1.024 on my Leopard system.
intels-mac-pro:~ intel$ nm /opt/intel/Compiler/11.1/067/lib/libimf.a | grep "UNIX2003"
intels-mac-pro:~ intel$ nm /opt/intel/Compiler/11.1/067/lib/*.a | grep "UNIX2003"
intels-mac-pro:~ intel$ nm /opt/intel/cc/10.1.024/lib/libimf.a | grep "UNIX2003"
intels-mac-pro:~ intel$ nm /opt/intel/cc/10.1.024/lib/*.a | grep "UNIX2003"
11-03-2009 02:32 AM
So I came back after the weekend, did a reboot, and its fine now?! The 10.1 lib do not contain any references to $UNIX2003 routines, and neither does the lib I compile. I must have been doing something wrong on Friday when I grep-ed the 10.1 lib.
Out of interest, there was still a single reference to $UNIX2003, which came from a call to the function clock(), but that was non-critical to my lib, so I could comment the code out. But by default, a call to clock on ICL 10.1 do generate a call to clock$UNIX2003.
11-03-2009 07:59 AM
I don't think clock$UNIX2003 is coming from the 10.1 libraries. Most likely, it's from the system library of your development system. If you specify -v on the command line, you will see all the libraries thatare linked.
intels-mac-pro:~ intel$ nm /opt/intel/cc/10.1.024/lib/lib* | grep clock
11-04-2009 09:57 AM
I was curious to see why clock$UNIX2003 was in the libarary. It turns out that you need to set the option
-mmacosx-version-min=10.4 to the command line. You need to add this to the "Additional command" in Xcode build settings. Setting the "Deployment target" does not work with 10.1 compiler.
intels-mac-pro:569223 intel$ cat foo.c
clock_t t = clock();
intels-mac-pro:569223 intel$ . /opt/intel/cc/10.1.024/bin/iccvars.sh
intels-mac-pro:569223 intel$ icc -staticlib -syslibroot /Xcode_3.1.3/SDKs/MacOSX10.4u.sdk foo.c -o libfoo.a
intels-mac-pro:569223 intel$ nm libfoo.a | grep clock
intels-mac-pro:569223 intel$ icc -staticlib -syslibroot /Xcode_3.1.3/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 foo.c -o libfoo.a
intels-mac-pro:569223 intel$ nm libfoo.a | grep clock