Search code examples
c++linuxlinkerg++intel-ipp

Problems linking static Intel IPP libraries on Linux with g++

I've been trying to move a project over from Xcode to Linux (Ubuntu x86 for now, but hopefully the statically-linked executable will run on an x86 CentOS machine? I hope I hope?). I have the whole project compiling but it fails at the linking stage-- it's giving me undefined references for all functions defined by IPP. This is probably something really small and silly but I've been beating my head over this for a couple days now and I can't get it to work.

Here's the compile statement (I also have a makefile that's generating the same errors):

g++ -static /opt/intel/ipp/6.0.1.071/ia32/lib/libippiemerged.a /opt/intel/ipp/6.0.1.071/ia32/lib/libippimerged.a /opt/intel/ipp/6.0.1.071/ia32/lib/libippsemerged.a /opt/intel/ipp/6.0.1.071/ia32/lib/libippsmerged.a /opt/intel/ipp/6.0.1.071/ia32/lib/libippcore.a -pthread -I /opt/intel/ipp/6.0.1.071/ia32/include -I tools/include -o main main.cpp pick_peak.cpp get_starting_segments.cpp get_segment_timing_differences.cpp recast_and_normalize_wave_file.cpp rhythm_score.cpp pitch_score.cpp pitch_curve.cpp tools/source/LocalBuffer.cpp tools/source/wave.cpp distance.cpp

...and here is the beginning of the long list of linker errors:

./main.o: In function `main':
main.cpp:(.text+0x13f): undefined reference to `ippsMalloc_16s'
main.cpp:(.text+0x166): undefined reference to `ippsMalloc_32f'
main.cpp:(.text+0x213): undefined reference to `ippsMalloc_16s'

Any ideas? FWIW, these are the IPP dependencies in my Xcode project that builds, links, and runs without a problem: "-lippiemerged", "-lippimerged", "-lippsemerged", "-lippsmerged", "-lippcore",

Thanks!

Solution

  • Your linking problem is likely due to the fact that your link line is completely backwards: archive libraries should follow source and object files on command line, not precede them. To understand why the order matters, read this.

    Also note that on Linux statically linked executables are significantly less portable than dynamically linked ones. In general, if you link system libraries dynamically on an older Linux system, it will work on all newer systems (I use ancient RedHat 6.2, and I haven't seen a system on which my executable will not run). This is not true for completely static executables; they may crash in all kinds of "interesting" ways when moved to a system with a different libc from the one against which they were linked.