Intel® Software Network

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,

Hello!

Could you show the link string for x86_64 MacOSX 10.6? I've tested the IPP 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 only Mac OS X difference 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.

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

Hello,

I attached test 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.

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

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

#include <ippi.h>

 

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

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

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

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 the problem of compiler or it is the problem 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.

Hi All!

Unfortunatelly it doesn't help, the simple example:

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

$ icc -V
Intel(R) C Intel(R) 64 Compiler Professional for applications running on Intel(R) 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<width; 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(R) C Intel(R) 64 Compiler Professional for applications running on Intel(R) 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?

It doens't depend on 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

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