I have an anomalous problem which appears to be related to the `xild' linker tool, which icpc invokes almost immediately in this link step when attempting to compile Qt 4.6 Tech Preview. The problem does not manifest if I create a very simple test case of a .cpp that exports one trivial function:
GNU ld on my system expects the --dynamic-list option to have its parameter specified with an equals sign `=' rather than a space ` '. If -Qoption doesn't know to put an equals sign instead of a space, then GNU ld is going to complain. I need to coerce icpc/xild to properly send along this option.
ipo: warning #11009: file format not recognized for /home/sean/Downloads/qt-everywhere-opensource-src-4.6.0-tp1/src/corelib/QtCore.dynlist
Huh? As I clearly specified, this .dynlist file is part of a command line option to GNU ld. IPO shouldn't be doing anything with it, so I'm confused why this is showing up at all.
ld: cannot open linker script file -soname: No such file or directory
Huh? As I clearly specified, -soname is a parameter to the linker, to be passed verbatim to GNU ld. Why does xild try to use this as a script file!? What part of my command line is telling xild that I'm trying to pass a script file?
I have tried about a hundred different ways of organizing this command line to get icpc, or even directly invoking xild, to cleanly link this object file. But it seems that the command line option parser is deficient in understanding exactly what I'm telling it to do, probably because xild has this very awkward way of invoking GNU ld behind my back, without giving me any control over that step at all.
I am very close to just using GCC for this project, but would very much like to get the performance optimizations of Intel's compiler toolchain if possible. Is there any way to adjust my commandline to support the features I am trying to use of GNU ld without having icpc/xild freak out?
Does it work better if you don't attempt to mix ipo with ld options which appear to assume plain gnu-style .o files?
I can link all the objects together using plain GNU ld and the command line options that are applicable to GNU ld. That's not a problem.
If I remove the GNU ld commandline options entirely, I get undefined symbols such as __dso_handle, which means that somehow I need to tell xild how to do the equivalent of what GNU ld would do.
Besides, doesn't the whole ipo step just create additional object files in /tmp and pass them all to GNU ld along with the options? That was my understanding, anyway. I had hoped that I _could_ mix IPO with ld options that are eventually passed down to GNU ld via xild. If not, then xild is extremely limited indeed.