link error with IPP 5.3, gcc 4.2.1, x86_64, MacOSX 10.6

link error with IPP 5.3, gcc 4.2.1, x86_64, MacOSX 10.6

Hi,

after upgrading MacOSX to 10.6 and switching my local development target architecture to x86/64 bit I get the following link error on my standard project:

ld: in /Library/Frameworks/Intel_IPP.framework/Versions/Current/lib/libippimerged.a(piswap_split_mx_ippiSwapChannels_8u_C4IR.o), ObjectFileAddressSpace::mappedAddress(0xFFFFFFFFFFFFFFFC) not in any section

What can I do about this?

Hints:
Versions: IPP5.3.1.056, gcc 4.2.1 on MacOSX 10.6 build 10A432

lipo -info /Library/Frameworks/Intel_IPP.framework/Versions/Current/lib/libippimerged.a
yields

Architectures in the fat file: /Library/Frameworks/Intel_IPP.framework/Versions/Current/lib/libippimerged.a are: x86_64 i386

This used to work before.

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

Quoting - oku
Hi,

after upgrading MacOSX to 10.6 and switching my local development target architecture to x86/64 bit I get the following link error on my standard project:

ld: in /Library/Frameworks/Intel_IPP.framework/Versions/Current/lib/libippimerged.a(piswap_split_mx_ippiSwapChannels_8u_C4IR.o), ObjectFileAddressSpace::mappedAddress(0xFFFFFFFFFFFFFFFC) not in any section

What can I do about this?

Hints:
Versions: IPP5.3.1.056, gcc 4.2.1 on MacOSX 10.6 build 10A432

lipo -info /Library/Frameworks/Intel_IPP.framework/Versions/Current/lib/libippimerged.a
yields

Architectures in the fat file: /Library/Frameworks/Intel_IPP.framework/Versions/Current/lib/libippimerged.a are: x86_64 i386

This used to work before.

Quoting - Gennady Fedorov (Intel)

Oliver,

Please try to choose dynamic linking when you built the code on SnowLeo with IPP 5.3.
It seems that the issue you encountered causing by incompatibility with SnoLeo binutils ( partically in ld tool ).
--Gennady

Hi Gennady,
thanks for answering. In the meantime, I figured out, how to set my build system back to use gcc 4.0 and 32 bit. This way, I can build a working 32 Bit application and link against the ipp, just like before - on Mac OS X 10.6.
I don't think, deploying all those dynamic ipp libraries is an option, but I will check anyway.
Until then, we will not be able to build a modern 64-bit-Cocoa-Application, which uses ipp.

Hello!

Could you show the link string for x86_64 MacOSX 10.6? I've tested theIPP 5.3 libraries on MacOSX 10.5 x86_64 - all ok.

Pavel.

It's not a Mac OS X version issue, but a gcc version issue. The link string looks the same. Using the gcc 4.0 linker, it works, using gcc 4.2.1, it doesn't. Maybe, you can reproduce it on Mac OS X 10.5 as well, by setting CC=gcc-4.2 in the makefile (or Xcode project or whatever you use). The onlyMac OS Xdifference is, on 10.6, gcc 4.2.1 is the default and /usr/bin/gcc links to /usr/bin/gcc-4.2 instead of /usr/bin/gcc-4.0.

Maybe there is an incompatibility with the .o and .a object formats between the bin utils of the two gcc versions. I think, Intel could just recompile and relink the libraries with the newer tools and distribute those, too. This could be done, when finally updating ipp to 6.x (!) for the Mac OS X platform, since I don't think the money we payed is old and incompatible with current goods...

Note: On Linux, using ipp with the gcc 4.2.1 tools works. So, the incompatibilty probably lies within the OS specific object format (elf vs. Mach-O).

Quoting - oku
It's not a Mac OS X version issue, but a gcc version issue. The link string looks the same. Using the gcc 4.0 linker, it works, using gcc 4.2.1, it doesn't. Maybe, you can reproduce it on Mac OS X 10.5 as well, by setting CC=gcc-4.2 in the makefile (or Xcode project or whatever you use). The onlyMac OS Xdifference is, on 10.6, gcc 4.2.1 is the default and /usr/bin/gcc links to /usr/bin/gcc-4.2 instead of /usr/bin/gcc-4.0.

Maybe there is an incompatibility with the .o and .a object formats between the bin utils of the two gcc versions. I think, Intel could just recompile and relink the libraries with the newer tools and distribute those, too. This could be done, when finally updating ipp to 6.x (!) for the Mac OS X platform, since I don't think the money we payed is old and incompatible with current goods...

Note: On Linux, using ipp with the gcc 4.2.1 tools works. So, the incompatibilty probably lies within the OS specific object format (elf vs. Mach-O).

Hello,

I compiled a simple test on 64-bit Mac OS X 10.6 and doesn't obtain any issues. You may see the version of compiler I used and my linking line below:

bash-3.2# gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

bash-3.2# gcc -o test_em64t_static test2.c -I/Library/Frameworks/Intel_IPP.framework/Versions/5.3.1.056/em64t/include -L/Library/Frameworks/Intel_IPP.framework/Versions/5.3.1.056/em64t/lib -lippiemerged -lippimerged -lippcore

Probably it will helps you. If not, could you please provide exact link line you use?

Thanks,
Art

Quoting - Artem Vorobiev (Intel)

Hello,

I compiled a simple test on 64-bit Mac OS X 10.6 and doesn't obtain any issues. You may see the version of compiler I used and my linking line below:

bash-3.2# gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

bash-3.2# gcc -o test_em64t_static test2.c -I/Library/Frameworks/Intel_IPP.framework/Versions/5.3.1.056/em64t/include -L/Library/Frameworks/Intel_IPP.framework/Versions/5.3.1.056/em64t/lib -lippiemerged -lippimerged -lippcore

Probably it will helps you. If not, could you please provide exact link line you use?

Thanks,
Art

Art,

thank you for trying, this is good news! I tried a simple sample for myself (just called ippiGetLibVersion()) and it worked as well!

Reproducing the exact situation I had last week, is a rather lengthy process (includes building Qt from the sources), and I don't have enough time left right now, so I will do it first thing tomorrow morning.

Thanks again,
oku

Aha! Calling an actual image function shows the error:

I used this test program:

#include

int main (int argc, char **argv)

{

const IppLibraryVersion* version = ippiGetLibVersion();

const Ipp8u* pSrc = 0;

IppiSize srcSize = {0, 0};

int srcStep = 0;

IppiRect srcROI = {0,0,0,0};

Ipp8u* pDst = 0;

int dstStep = 0;

IppiSize dstRoiSize = {0,0};

double xFactor = 0;

double yFactor = 0;

int interpolation = 0;

IppStatus status = ippiResize_8u_C3R (pSrc, srcSize, srcStep, srcROI, pDst, dstStep, dstRoiSize, xFactor, yFactor, interpolation);

return 0;

}

...and compiled and linked it using this line:

gcc-4.2 -arch x86_64 main.c -I /Library/Frameworks/Intel_IPP.framework/Versions/Current/include/ -L/Library/Frameworks/Intel_IPP.framework/Versions/Current/lib/ -lippiemerged -lippimerged -lippcore -o ippTest

which led to:

ld: in /Library/Frameworks/Intel_IPP.framework/Versions/Current/lib//libippimerged.a(piresnn_split_y8_ownResize16plN.o), ObjectFileAddressSpace::mappedAddress(0xFFFFFFFFFFFFFFFC) not in any section

collect2: ld returned 1 exit status

Quoting - oku

Aha! Calling an actual image function shows the error:

I used this test program:

#include

int main (int argc, char **argv)

{

const IppLibraryVersion* version = ippiGetLibVersion();

const Ipp8u* pSrc = 0;

IppiSize srcSize = {0, 0};

int srcStep = 0;

IppiRect srcROI = {0,0,0,0};

Ipp8u* pDst = 0;

int dstStep = 0;

IppiSize dstRoiSize = {0,0};

double xFactor = 0;

double yFactor = 0;

int interpolation = 0;

IppStatus status = ippiResize_8u_C3R (pSrc, srcSize, srcStep, srcROI, pDst, dstStep, dstRoiSize, xFactor, yFactor, interpolation);

return 0;

}

...and compiled and linked it using this line:

gcc-4.2 -arch x86_64 main.c -I /Library/Frameworks/Intel_IPP.framework/Versions/Current/include/ -L/Library/Frameworks/Intel_IPP.framework/Versions/Current/lib/ -lippiemerged -lippimerged -lippcore -o ippTest

which led to:

ld: in /Library/Frameworks/Intel_IPP.framework/Versions/Current/lib//libippimerged.a(piresnn_split_y8_ownResize16plN.o), ObjectFileAddressSpace::mappedAddress(0xFFFFFFFFFFFFFFFC) not in any section

collect2: ld returned 1 exit status

Hello,

I attachedtest case with makefile to this post. I built and run this example successfully. Could you please build it on your side?

Thanks,
Art

P.S. To unpack this archive please invoke the next command:

tar xzvf ipptest.tar.gz

It will create directory ipptest with makefile and test2.c files.

Attachments: 

AttachmentSize
Downloadapplication/octet-stream ipptest.tar.gz705 bytes

Quoting - Artem Vorobiev (Intel)
I attachedtest case with makefile to this post. I built and run this example successfully. Could you please build it on your side?

Your sample works. The output is:

ippiSwapChannels_8u_C3R PASSED
SRC
255 0 0 255 0 0 255 0 0 255 0 0
0 255 0 0 255 0 0 255 0 0 255 0
0 0 255 0 0 255 0 0 255 0 0 255

DST
0 0 255 0 0 255 0 0 255 0 0 255
0 255 0 0 255 0 0 255 0 0 255 0
255 0 0 255 0 0 255 0 0 255 0 0

This is interesting. There are functions which work, and some which don't? Did you in turn try my sample as well? The Resize call is one of those we actually use in the project, so that really matters.

Quoting - oku

Your sample works. The output is:

ippiSwapChannels_8u_C3R PASSED
SRC
255 0 0 255 0 0 255 0 0 255 0 0
0 255 0 0 255 0 0 255 0 0 255 0
0 0 255 0 0 255 0 0 255 0 0 255

DST
0 0 255 0 0 255 0 0 255 0 0 255
0 255 0 0 255 0 0 255 0 0 255 0
255 0 0 255 0 0 255 0 0 255 0 0

This is interesting. There are functions which work, and some which don't? Did you in turn try my sample as well? The Resize call is one of those we actually use in the project, so that really matters.

Hi Oliver!

Unfortunatelly I don't have MacOSX 10.6 right now and can't reproduce your sample, but as I can see:

Artem uses ippStaticInit() function before using any other IPP functions and it is correct. The emerged + merged librararies - are the static dispatcher and merged static library and you should initialize static dispatche by calling ippStaticInit.

Please try to call ippStaticInit function before.

Thanks, Pavel

Quoting - Pavel Berdnikov

Hi Oliver!

Unfortunatelly I don't have MacOSX 10.6 right now and can't reproduce your sample, but as I can see:

Artem uses ippStaticInit() function before using any other IPP functions and it is correct. The emerged + merged librararies - are the static dispatcher and merged static library and you should initialize static dispatche by calling ippStaticInit.

Please try to call ippStaticInit function before.

Thanks, Pavel

I did that and the linker still can't link:

main.c:

#include

int main (int argc, char **argv)

{

ippStaticInit();

const IppLibraryVersion* version = ippiGetLibVersion();

const Ipp8u* pSrc = 0;

IppiSize srcSize = {0, 0};

int srcStep = 0;

IppiRect srcROI = {0,0,0,0};

Ipp8u* pDst = 0;

int dstStep = 0;

IppiSize dstRoiSize = {0,0};

double xFactor = 0;

double yFactor = 0;

int interpolation = 0;

IppStatus status = ippiResize_8u_C3R (pSrc, srcSize, srcStep, srcROI, pDst, dstStep, dstRoiSize, xFactor, yFactor, interpolation);

return 0;

}

command line:

gcc-4.2 -arch x86_64 main.c -I /Library/Frameworks/Intel_IPP.framework/Versions/Current/include/ -L/Library/Frameworks/Intel_IPP.framework/Versions/5.3.1.056/em64t/lib -lippiemerged -lippimerged -lippcore -o ippTest

ld: in /Library/Frameworks/Intel_IPP.framework/Versions/5.3.1.056/em64t/lib/libippimerged.a(piresnn_split_y8_ownResize16plN.o), ObjectFileAddressSpace::mappedAddress(0xFFFFFFFFFFFFFFFC) not in any section

collect2: ld returned 1 exit status

...as expected, because not calling the init function may lead to runtime errors, but not to link errors.

I did some more tests, and found out, it does not depend on the gcc version. These command lines work:

gcc-4.0 -arch i386 main.c -I /Library/Frameworks/Intel_IPP.framework/Versions/Current/include/ -L/Library/Frameworks/Intel_IPP.framework/Versions/Current/lib/ -lippiemerged -lippimerged -lippsmerged -lippsemerged -lippcore -o ippTest

gcc-4.2 -arch i386 main.c -I /Library/Frameworks/Intel_IPP.framework/Versions/Current/include/ -L/Library/Frameworks/Intel_IPP.framework/Versions/Current/lib/ -lippiemerged -lippimerged -lippsmerged -lippsemerged -lippcore -o ippTest

gcc-4.2
-arch x86_64 main.c -I /Library/Frameworks/Intel_IPP.framework/Versions/Current/include/ -L/Library/Frameworks/Intel_IPP.framework/Versions/Current/Libraries -lippi -lipps -lippcore -o ippTest

These don't:

gcc-4.0 -arch x86_64 main.c -I /Library/Frameworks/Intel_IPP.framework/Versions/Current/include/ -L/Library/Frameworks/Intel_IPP.framework/Versions/Current/lib/ -lippiemerged -lippimerged -lippsmerged -lippsemerged -lippcore -o ippTest

gcc-4.2 -arch x86_64 main.c -I /Library/Frameworks/Intel_IPP.framework/Versions/Current/include/ -L/Library/Frameworks/Intel_IPP.framework/Versions/Current/lib/ -lippiemerged -lippimerged -lippsmerged -lippsemerged -lippcore -o ippTest

So, unlike, what I suspected earlier, both, gcc 4.0 and 4.2 work with static libraries when targeting the 32 bit architecture on MacOSX 10.6, and fail, when switching to the x86_64 architecture. But this works as well, when using dynamic linking.

Hi Oliver!

Yes it is the tools conflict, I can reproduce this situation. I'll investigate it and report you about result.

Thank you, Pavel

Hello,

FYI, I have problem with this in 10.6 as well.

Cheers,
Mikael

Hello again,

Have you made any progress on this issue? I would really like the 64 bit compliation. For me both 32 and 64 bit works on 10.5 but only 32 bit works on 10.6. 64 bit give me the error in the original post.

Btw, I use the 6.1u1 version with the IPP compiler. Static linking (can't go dynamic).

Cheers,
Mikael

Hello, the investigaion of this problem shows incompatilbe between compiler and ld from MacOSX 10.6. No such problem on MacOSX 10.5. I don't know yet is it theproblem of compiler or it is theproblem of ld. It is inverstigating right now.
I could suggest only one way rign now: use MacOSX 10.5 for linking your application. It works well.

Pavel.


Quoting - Pavel Berdnikov

Hello, the investigaion of this problem shows incompatilbe between compiler and ld from MacOSX 10.6. No such problem on MacOSX 10.5. I don't know yet is it theproblem of compiler or it is theproblem of ld. It is inverstigating right now.
I could suggest only one way rign now: use MacOSX 10.5 for linking your application. It works well.

Pavel.

Thanks Pavel.

Quoting - Pavel Berdnikov

Hello, the investigaion of this problem shows incompatilbe between compiler and ld from MacOSX 10.6. No such problem on MacOSX 10.5. I don't know yet is it theproblem of compiler or it is theproblem of ld. It is inverstigating right now.
I could suggest only one way rign now: use MacOSX 10.5 for linking your application. It works well.

Pavel.

Hi Pavel,

what about the other way round? If you create the static ipp libs on 10.6, canyou link them on 10.5? If this is the case, Intel could just distribute new libs (created on 10.6).

oku

Quoting - oku

Hi Pavel,

what about the other way round? If you create the static ipp libs on 10.6, canyou link them on 10.5? If this is the case, Intel could just distribute new libs (created on 10.6).

oku

Hi All!

Unfortunatelly it doesn't help, the simple example:

$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.6
BuildVersion: 10A333

$ icc -V
Intel C Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build 20090325
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.

$
$ cat test.c

#define CHANNELS_C1 1
#define CHANNELS_C3 3
#define CHANNELS_AC4 4
#define MAX( a, b ) ( ((a) > (b)) ? (a) : (b) )

__inline float Max3Vert_32f(const float* src, int srcStep)
{
float x = MAX(*src, *((float*)((char*)src+srcStep)));
return MAX(x, *((float*)((char*)src+2*srcStep)));
}

__inline float Max3_32f(const float* src)
{
float x = MAX(src[0], src[1]);
return MAX(x, src[2]);
}

int myfunc( const float* pSrc, int srcStep, float* pDst, int width)
{
int c;
float local[CHANNELS_C3*3];
int locIndex= 0;

for(c=1; c local[locIndex] = Max3Vert_32f(pSrc, srcStep);
local[locIndex+CHANNELS_C3] = Max3Vert_32f(pSrc+1, srcStep);
local[locIndex+CHANNELS_C3*2]= Max3Vert_32f(pSrc+2, srcStep);
pDst[0+CHANNELS_AC4] = Max3_32f(local);
pDst[1+CHANNELS_AC4] = Max3_32f(local+CHANNELS_C3);
pDst[2+CHANNELS_AC4] = Max3_32f(local+CHANNELS_C3*2);
locIndex++;
if(locIndex>2) locIndex = 0;
pSrc += CHANNELS_AC4;
pDst += CHANNELS_AC4;
}
return 0;
}

$ icc -c test.c -o test.o
$
$ echo -e "_myfunc" >lib.script
$
$ libtool -dynamic -arch_only x86_64 -exported_symbols_list ./lib.script test.o -o libmytest.dylib
ld: in test.o, ObjectFileAddressSpace::mappedAddress(0xFFFFFFFFFFFFFFFC) not in any section
libtool: internal link edit command failed

go to the MacOSX 10.5:

$sw_vers
ProductName: Mac OS X
ProductVersion: 10.5.6
BuildVersion: 9G66

And try to link the same object into dynamic library:

$libtool -dynamic -arch_only x86_64 -exported_symbols_list ./lib.script test.o -o libmytest.dylib
$

No problem, recompile this sample on MacOSX 10.5 and link again:

$icc -V
Intel C Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build 20090325
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.

$
$icc -c test.c -o test.o
$libtool -dynamic -arch_only x86_64 -exported_symbols_list ./lib.script test.o -o libmytest.dylib
$

No problem.

I don't know: is it the problem of the Intel compiler or the problem of new ld in MacOSX 10.6, but the problem is on the MacOSX 10.6 and no problem on the MacOSX 10.5.

Because right now the single way to use ld from MacOSX 10.5

Pavel

Yes, you have proven (like me), that a static IPP library, which was created on MacOSX 10.5 (or before), can not be used on MacOSX 10.6. But maybe a static IPP library created on MacOSX 10.6 can be linked on MacOSX 10.5?

Quoting - oku
Yes, you have proven (like me), that a static IPP library, which was created on MacOSX 10.5 (or before), can not be used on MacOSX 10.6. But maybe a static IPP library created on MacOSX 10.6 can be linked on MacOSX 10.5?

It doens't dependon which version of MacOSX used for compiling, I compile my test.c on MacOSX 10.6 and the problem are. It depend only from Intel compiler and version of ld. It is the reason why I suggest to use MacOSX 10.5 for linking your application.
I don't know what the reason of problem: Intel compiler or new version of ld, it is investigation right now.

Pavel.

Pavel,

Do you work at or for Intel? If not, is there anyone at Intel that is looking at this?

I want my Snow Leopard.

Cheers,
Mikael

Quoting - Pavel Berdnikov

It doens't dependon which version of MacOSX used for compiling, I compile my test.c on MacOSX 10.6 and the problem are.
Maybe I didn't make myself clear enough: I was talking about the ipp library itself. Genrerally, static libraries created on MacOSX 10.6 can of course be linked on MacOSX 10.6!
It depend only from Intel compiler and version of ld. It is the reason why I suggest to use MacOSX 10.5 for linking your application.
I don't know what the reason of problem: Intel compiler or new version of ld, it is investigation right now.

I do not use the Intel compiler at all. I am using gcc for compiling, as well as for linking, so the Intel compiler can not be the problem when USING the library. It CAN on the other hand be the problem when CREATING the static IPP libs (I guess, Intel use their own compiler for compiling the IPP).

I can not test this myself, since I would need the IPP source code. Only somebody at Intel with access to the IPP source code can do this: Create the static IPP libs on MacOSX 10.6 using the bin utils available there. I am almost sure, those could be linked on MacOSX 10.6. The only question would be, could those be linked on MacOSX 10.5 as well? If this is the case, Intel could distribute those and all would be well.

This issues looks like it's related to a known issue with the compiler documented here. We found this problem during the 11.1 compiler beta, and the compiler / compiler runtime libraries was fixed during the 11.1 beta. This was both a problem with the compiler, and a change in the ld tool for OSX 10.6.

It looks like the performance libraries are built with an older compiler.

Quoting - Qale (Intel)

This issues looks like it's related to a known issue with the compiler documented here. We found this problem during the 11.1 compiler beta, and the compiler / compiler runtime libraries was fixed during the 11.1 beta. This was both a problem with the compiler, and a change in the ld tool for OSX 10.6.

It looks like the performance libraries are built with an older compiler.

Hello Qale,

Is there any official (or unofficial, which I won't hold you to) date for an update that fixes this?

Cheers,
Mikael

Quoting - mikaelgrev

Hello Qale,

Is there any official (or unofficial, which I won't hold you to) date for an update that fixes this?

Cheers,
Mikael

No datethat I know of, I only saw this thread today. The performance library folks are aware of this. You should file a bug at https://premier.intel.com to get update on a fix.

If possible, try linking against the dynamic version of the library to see if that works for you.

Quoting - mikaelgrev

Hello Qale,

Is there any official (or unofficial, which I won't hold you to) date for an update that fixes this?

Cheers,
Mikael

Hello Mikael!

The IPP 6.1 gold will be released with fixing thebug for MacOSX 10.6. It will be IPP 6.1 gold update 2 or 3. I don't know exactly right now and don't know about the date right now. I'll say about date late.

Pavel.

Quoting - Pavel Berdnikov

Hello Mikael!

The IPP 6.1 gold will be released with fixing thebug for MacOSX 10.6. It will be IPP 6.1 gold update 2 or 3. I don't know exactly right now and don't know about the date right now. I'll say about date late.

Pavel.

Thanks Pavel!

Much appreciated.

Micke

Quoting - Pavel Berdnikov

Hello Mikael!

The IPP 6.1 gold will be released with fixing thebug for MacOSX 10.6. It will be IPP 6.1 gold update 2 or 3. I don't know exactly right now and don't know about the date right now. I'll say about date late.

Pavel.

Thank you: finally, these are good news!

Hi All!

the IPP 6.1 gold update 2 without this bug will be soon (1-2 weeks)

Pavel

Hello,

The Intel C++ Compiler Professional Edition 11.1 Update 3 for Mac OS X is avalaible now at the Intel Registration Center.

bash-3.2# cat csupport
Package ID: m_cproc_p_11.1.076

This package contains:
Intel C++ Compiler for Mac OS* X version 11.1
Intel Debugger for Mac OS* X version 11.1
Intel Integrated Performance Primitives 6.1 Update 2 for Mac OS* X
Intel Math Kernel Library 10.2 Update 2 for Mac OS* X
Intel Threading Building Blocks 2.2 for Mac OS X, Update 1

For information about how to find Technical Support, Product Updates, User Forums, FAQs, tips and tricks, and other support information, please visit http://www.intel.com/software/products/support/cmac .

Note: If your distributor provides technical support for this product, please contact them for support rather than Intel.

You need a valid license to use this product.bash-3.2#

I checked two examples of unsuccessful linking from posts #8 and #19. Please see the results below.

My configuration:
bash-3.2# icc -V
Intel C Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build 20091012 Package ID: m_cproc_p_11.1.076
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.
bash-3.2# sw_vers
ProductName: Mac OS X
ProductVersion: 10.6
BuildVersion: 10A432

#8:
bash-3.2# gcc-4.2 -arch x86_64 main.c -I /opt/intel/Compiler/11.1
/076/Frameworks/ipp/include/ -L/opt/intel/Compiler/11.1/076/Frameworks/ipp/lib -lippsemerged -lippsmerged -lippiemerged -lippimerged -lippcore -o ippTest
main.c: In function 'main':
main.c:18: warning: 'ippiResize_8u_C3R' is deprecated (declared at /opt/intel/Compiler/11.1/076/Frameworks/ipp/include/ippi.h:5087)

I added two libraries into original link line. Without this unresolved dependencies error will be obtained.

#19:
bash-3.2# icc -c test.c -o test.o
bash-3.2# echo -e "_myfunc" > lib.script
bash-3.2# libtool -dynamic -arch_only x86_64 -exported_symbols_list ./lib.script test.o -o libmytest.dylib
bash-3.2#

Thanks,
Art

Hi Mikael,

This problem has been fixed in IPP 6.1 update 2 release. This package is included in the latest Compiler Professional Edition for Mac OS* X, Version 11.1 Update 3.

Thanks,
Chao

Quoting - Chao Y (Intel)
Hi Mikael,

This problem has been fixed in IPP 6.1 update 2 release. This package is included in the latest Compiler Professional Edition for Mac OS* X, Version 11.1 Update 3.

Thanks,
Chao

Thank you Chao!

I will try it asap. And upgrade my other computers to Snow Leaoperd. :)

Cheers,
Mikael

Leave a Comment

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