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

[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.

[Gennady_F_Intel]

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.

[Gennady_F_Intel]

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

[oku]

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.

[Pavel_B_Intel1]

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.

[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).

[Artem_V_Intel]

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

[oku]

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

[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

[Artem_V_Intel]

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.

[oku]

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.

[Pavel_B_Intel1]

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

[oku]

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.

[Pavel_B_Intel1]

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

[Mikael_Grev]

Hello,

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

Cheers,
Mikael

[Mikael_Grev]

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

[Pavel_B_Intel1]

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.

[Mikael_Grev]

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.

[oku]

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

[Pavel_B_Intel1]

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

[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?