- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am using the IPP 7.0.4 version of the library on Mac OSX 10.6.
I am statically linking the IPP / UMC H264 video decoder into our application with all the static libraries needed. I am still seeing one missing symbol (error from g++ 4.2.1):
Undefined symbols:
"___libm_sse2_sin", referenced from:
_ownResizeInitAALAd in libippi.a(piresaa_split_p8_ownResizeInitAAD.o)
_ownResizeInitAALA in libippi.a(piresaa_split_v8_ownResizeInitAA.o)
_ownResizeInitAALAd in libippi.a(piresaa_split_w7_ownResizeInitAAD.o)
_ownResizeInitAALA in libippi.a(piresaa_split_p8_ownResizeInitAA.o)
_ownResizeInitAALA in libippi.a(piresaa_split_w7_ownResizeInitAA.o)
_ownResizeInitAALAd in libippi.a(piresaa_split_v8_ownResizeInitAAD.o)
I have run "nm" on all IPP .a files in the library, and this symbol is not defined. I did find the symbol however, in several of the dynamic libs including the "libippacv8-7.0.dylib", but with local "t" scope with means it is not externally accessible. So, I am currently unable to link statically at all.
We very much want to link this all statically without external dependencies. Do you also see this symbol missing from the static versions of the IPP library? If so, how do I request an updated version that includes it?
Best regards,
Herrick
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Herrick,
The symbols are in the compiler runtime libraries. Add the compiler runtime libraries(libimf.a) at /composerxe-2011.4.191/compiler/lib/ folder, and see how it works
Thanks,
Chao
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The symbol is not there. Do you see it when you run "nm" on that library?
I ran this command:
nm /opt/intel/composerxe-2011.4.184/compiler/lib/libimf.a | grep ___libm_sse2_sin
Which only includes entries for "___libm_sse2_sincos" not "___libm_sse2_sin":
Output:
U ___libm_sse2_sincos
U ___libm_sse2_sincos
U ___libm_sse2_sincos
U ___libm_sse2_sincosf
U ___libm_sse2_sincos
0000000000000000 T ___libm_sse2_sincos
0000000000001678 S ___libm_sse2_sincos.eh
U ___libm_sse2_sincos
0000000000000000 T ___libm_sse2_sincosf
0000000000000698 S ___libm_sse2_sincosf.eh
U ___libm_sse2_sincos
U ___libm_sse2_sincos
U ___libm_sse2_sincos
U ___libm_sse2_sincos
U ___libm_sse2_sincos
U ___libm_sse2_sincos
U ___libm_sse2_sincos
U ___libm_sse2_sincos
Thanks,
Herrick
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Are you build a 32bit application, right? If yes, could you checkif you have the directory like/opt/intel/composerxe-2011.4.184/compiler/lib/ia32 installed?
As i know, the symbols is required and provided by 32bit libimf.a, no requiredby 64 bit application.
[ ia32]$ nm libimf.a | grep __libm_sse2_sin
0000000000000000 T __libm_sse2_sincosf
0000000000000000 T __libm_sse2_sincos
0000000000000000 T __libm_sse2_sinf
0000000000000000 T __libm_sse2_sin
Regards,
Ying
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am indeed building this as a 32-bit application. I see both "ia32" and "intel64" directories under "/opt/intel/composerxe-2011.4.184/compiler/lib".
Running "file libimf.a" produces:
libimf.a: Mach-O universal binary with 2 architectures
libimf.a (for architecture x86_64): current ar archive random library
libimf.a (for architecture i386): current ar archive
Then if I run nm as "nm -arch i386 libimf.a|grep ___libm_sse2_sin"
I do finally see the output you show above.
00000040 T ___libm_sse2_sin
00000040 T ___libm_sse2_sincos
00000010 T ___libm_sse2_sincosf
00000010 T ___libm_sse2_sinf
I added the libimf.a to the build and it works!
Thanks again!
Herrick
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Static library missing symbol ___libm_sse2_sin I am re-linking all static libraries with my own .a and I am seeing this error from ld: /usr/bin/libtool: for architecture i386 object: /opt/intel/composerxe-2011.4.184/compiler/lib/libiomp5.a(iomp.o) malformed object (LC_SEGMENT command 0 filesize field greater than vmsize field) Am I missing another .a file to link against? Thanks, Herrick | |||
Edit | Delete | Reply | Report Abuse| Mark as Best Answer |
Ying H (Intel)![]() | June 20, 2011 10:09 PM PDT | Rate | #2 |
---|---|---|---|
Static library missing symbol ___libm_sse2_sin Hi Herrick, |
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Undefined symbols:
"___kmpc_barrier", referenced from:
_w7_ippiResizeSqrPixel_16u_C1R in libippi.a(piresize2_split_w7_ippiResizeSqrPixel_16u_C1R.o)
...
"___kmpc_fork_call", referenced from:
_w7_ippiResizeSqrPixel_16u_C1R in libippi.a(piresize2_split_w7_ippiResizeSqrPixel_16u_C1R.o)
...
"_omp_get_num_procs", referenced from:
_ippStaticInitCpu in libippcore.a(ippmrgjump.o)
...
"_omp_get_max_threads", referenced from:
_ippStaticInitCpu in libippcore.a(ippmrgjump.o)
Thoughts?
Thanks for your time,
Herrick
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Like I mentioned above, if I statically link to the ipp libraries, and not the libiomp5 library as you suggest, I get the above linker errors.
Some other library used by the H264 decoder must be requiring the libiomp5 or a library that requires it.
I have not heard any response from the compiler team regarding the new thread you created. Could you please advise the best thing to try at this point?
As I mentioned in the complier forum thread, the libiomp5.a file seems to be unknown to the gcc/ld/nm toolchain.
Please let me know if you can assist.
Thanks,
Herrick
- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Herrick,
Could you please check if you have serial IPPstatic library linked.
It's name should be like libipp*_l.a, which don't depend libiomp5.a.
For example, link libippcore_l.a instead of libippcore.a, which is a symlink to ipp*_t.a (threaded library).
Thanks
Ying
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, the static build now completes, but I am now seeing hundreds of warnings like this when I relink all .a files together:
/usr/bin/libtool: warning for architecture: x86_64 same member name (pvcvc1transformfwdm7as.o) in output file used for input files: .../libippvc_l.a(pvcvc1transformfwdm7as.o) and: .../libippvc_l.a(pvcvc1transformfwdm7as.o) due to use of basename, truncation and blank padding
Is this due to the mix of both i386 and x86_64 binaries in the .a files?
It seems to be working regardless, but I would like to understand the warning and remove it.
Thanks,
Herrick
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Herrick,
"Is this due to the mix of both i386 and x86_64 binaries in the .a files?"
I think no, FAT technology is stable and should not generate any issue.
Probably the issue with "when I relink all .a files together"? Could you please list the exact command line?
Thanks
Ying

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