Compiler uses binutils ld instead of xild?

[bsteintrc]

In reviewing part of our compiler setup the other day, we discovered that our build system was calling the gnu archiver (ar) instead of the one that comes with icc (xiar). It seems to eventually call ar (hopefully after some preprocessing), which is fine. However, I decided to watch what the link steps were doing, and discovered that was calling gnu's ld, instead of the icc xild. It seems to do something similar to xiar (some preprocessing and then call gnu's ld), but it does make me wonder, if it isn't being called.

Interestingly, my strace output shows that icc is looking in for ld. xild exists there, but not ld. Then it continues searching my path and picks up the gnu one (in /usr/bin/). I could call xild directly, I suppose, but it's getting invoked automatically by icc/icpc, just like gcc/g++ calls ld implicitly when linking.

Is this something to be concerned about? Is there some way to get icc to use xild first? Should I even care?

Thanks for your time and help.

http://gerrit.tower-research.com/#change,14

[TimP]

gnu ld should work, if you never set -ipo, which will require the xild and xiar tools. Otherwise, you will get a clear failure to build.

[bsteintrc]

Good to know, thanks.
if I do use -ipo, will icc automaticall call the correct one? Or will I have to do something extra?

Edit: Easy test - took a hello world program, and compiled as thus:
icpc hello.cpp -ipo -o hello
ran it through strace, and still no reference to xild. Or is the compiler being even smarter, and realizing that it stll doesn't need xild?

[TimP]

Quoting bsteintrc

Good to know, thanks.
if I do use -ipo, will icc automaticall call the correct one? Or will I have to do something extra?

Edit: Easy test - took a hello world program, and compiled as thus:
icpc hello.cpp -ipo -o hello
ran it through strace, and still no reference to xild. Or is the compiler being even smarter, and realizing that it stll doesn't need xild?

Probably so; the pre-link step should scan the .o files (only 1 of them) to see what steps are required prior to invoking ld.

[bsteintrc]

You're right. Trying it with a multi-file setup and -ipo, I see the system calling xild. Talk about the compiler being too smart for it's own good. :)

Though it does seem a little odd - I would have expected it to just always call xild, if it can. It also seems slightly odd, since I'm guessing there's no way to use xiar without specifying it explicitly, since icc doesn't call that one itself.

Thanks agan for your help!

[tao_w_1]

Why cannot I see icpc calls xild with multi-file -ipo set up? (source code: https://codesign.llnl.gov/lulesh/lulesh2.0.3.tgz)

strace icpc -DUSE_MPI=0 lulesh.cc lulesh-comm.cc lulesh-viz.cc lulesh-util.cc lulesh-init.cc  -v -qopenmp -ipo -lm -o lulesh2.0 &>t

I can only see gnu ld is called.

It is really confusing.

[tao_w_1]

In my mind, the compilation is as follows (https://software.intel.com/en-us/articles/using-intel-c-compiler-for-embedded-system)

There are two possible models and they should be able to generate the same binary.

However, my experiment w/ LULESH 2.0 does not support such a claim.

I compare the two generated executables with diff. 

My question is: is the claim wrong or I should use other tool to compare executables generated by the following two models?

[Model 1: explicitly link w/ xild for ipo]

1. icpc -ipo *.cc to compile each .cc file into object file with Intel intermediate IR.

2. xild performs IPO with *.o (with Intel IR)

3. xild invoke gnu ld to link libraries and generate final executable.

[Model 2: implicitly link w/ icpc for ipo]

1. same as 1 in Model 1.

2. icpc -DUSE_MPI=0 lulesh.o lulesh-comm.o lulesh-viz.o lulesh-util.o lulesh-init.o  (may or may not add -ipo flag)

//icpc will do ipo and then invoke ld to generate final executable.