- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
#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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
#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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ippiSwapChannels_8u_C3R PASSEDSRC255 0 0 255 0 0 255 0 0 255 0 00 255 0 0 255 0 0 255 0 0 255 00 0 255 0 0 255 0 0 255 0 0 255DST0 0 255 0 0 255 0 0 255 0 0 2550 255 0 0 255 0 0 255 0 0 255 0255 0 0 255 0 0 255 0 0 255 0 0
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ippiSwapChannels_8u_C3R PASSEDSRC255 0 0 255 0 0 255 0 0 255 0 00 255 0 0 255 0 0 255 0 0 255 00 0 255 0 0 255 0 0 255 0 0 255DST0 0 255 0 0 255 0 0 255 0 0 2550 255 0 0 255 0 0 255 0 0 255 0255 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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 ippTestgcc-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 ippTestgcc-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 ippTestgcc-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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
FYI, I have problem with this in 10.6 as well.
Cheers,
Mikael
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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+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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page