Showing results for 
Search instead for 
Did you mean: 

problem with the x86_64-k1om-linux-ld: warning

Hi dear staff,

I try to compile the bwa ( on xeon host for xeon phi, but I get some warnings like this:

x86_64-k1om-linux-ld: warning:, needed by /local/tmp.schen/lib/, not found (try using -rpath or -rpath-link)
x86_64-k1om-linux-ld: warning:, needed by /local/tmp.schen/lib/, not found (try using -rpath or -rpath-link)
x86_64-k1om-linux-ld: warning:, needed by /local/tmp.schen/lib/, not found (try using -rpath or -rpath-link)
x86_64-k1om-linux-ld: warning:, needed by /local/tmp.schen/lib/, not found (try using -rpath or -rpath-link)

I try to solve it by using the -rpath like

But it still is unsuccessful, my account on xeon phi doesn't have the root permission, so I can't upload these files into xeon phi directly.

Do you have any other methods to solve this problem?




0 Kudos
3 Replies


you can solve it by adding -Wl,-rpath,yourlibs-address


New Contributor I

I just ran into this same problem and using -Wl,-rpath=/opt/intel/composer.../compiler/lib/mic does solve the warnings, but my question is why? 

  • the path in the rpath above is included as part of a "-L" option
  • -limf, -lsvml, ... are all preceded by -Bstatic so I'm thinking I shouldn't be linking with shared objects (which is what the ld manual says -rpath is for)
  • when I do ldd on my application (with -rpath) it says it's "not a dynamic executable" so why did I need to specify a run time path
  • If I don't add -rpath and just ignore the warnings, I seem to get a perfectly good executable anyway.

Given all this, I really appreciate if someone could explain what's going so that I can learn something.

(this is using 15.0.2 and, unfortunately, my "screen shot" is too big to type in unless someone really needs to see the details).

New Contributor III


I don't fully understand all details, but here's roughly what happens:

- when you build zlib for the mic, it is run-time linked against libimf, libsvml, libirng and libintlc5 . This is done automatically by the linker. You can verify this by running this command on the Mic:


$  ldd (0x00007ffe0cdff000) => /lib64/ (0x00007f89ba33d000) => /usr/lib64/ (0x00007f89b9eec000) => /usr/lib64/ (0x00007f89b96f7000) => /usr/lib64/ (0x00007f89b94e4000) => /lib64/ (0x00007f89b92a5000) => /usr/lib64/ (0x00007f89b8f7b000) => /lib64/ (0x00007f89b8d67000) => /usr/lib64/ (0x00007f89b8b46000) => /lib64/ (0x00007f89b8928000) => /lib64/ (0x00007f89b8724000)
	/lib64/ (0x00007f89ba8b3000)


Now , when you link against libz but you do not explicitly include the libs listed above then the linker cannot resolve the full runtime libraries and it complains as shown. You can either

  • include the libraries using "-l ..."
  • link using -Wl,-rpath,yourlibs-address

so that the linker won't complain about the missing shared libraries. Another alternative is to link against a static version of libz (libz.a) and most of the warnings should go away.

The fact that the binary works even without the -rpath listed is caused by "lazy loading" : if a shared lib that that needs to be loaded by another shared library is present at runtime (but not at link-time) , the loader will load it automagically for you.

I hope this info helps you, or that someone with better knowledge of the Intel compiler suite can explain more in detail what is happening here.


The question that still nags me is:

How do I avoid this runtime dependency and how can I build and link against an Intel supplied RPM (e.g. libz-dev-1.2.6-r1.k1om.rpm) on the *host* ?