Hi. I'm trying to compile my project, and when linking, I get the following warning:
ipo: warning #11010: file format not recognized for
After an extensive search, this thread seemed most helpful:
However, when I tried switching ar to xiar, I get the following output for the lib:
xiar: executing 'ar'
And then the same problem as above. I'm not trying to do anything fancy with flags (I'm not even using -ipo, to my knowlege), and I believe everything should be using the icc toolchain (and not gcc).
Any help would be greatly appreciated.
It seems the same issue as the post you pointed out.
xiar will process the ipo format .o files and then call ar to process further for .a. Please add some debug msg to your build scripts to see if the warning #11010 comes from xiar.
I guess I wan't clear enough. I've built with debug output higher (the build system being used is bjam), and I can see what's called when and which causing warnings.
The .a files are created by xiar, which only outputs the 'executing ar" message.
Then, later, another call to icpc (that lists the .a for linking) causes this warning.
tim18, I've tried removing all the .a files, and removing the entire build directory, so it's not a problem with old files. A good guess, though. I thought that might have been it, too.
I'd also like to ask for clarification about this warning. What, exactly, is it saying? My program still builds, but I do like it to be clear of warnings, if possible. Is this ignoring the .a file because it can't process it, or only using part of it, or what? Does it mean that the program might fail randomly at some point, not finding something not-often used?
When I do that, I get these *additional* warning (for each .o):
ipo: warning #11003: no IR in object file
Along with the #11010 warnings.
The same thing happens if I try to add the -qipo to the xiar call.
I supposed I could try adding -ipo to every call, but that doesn't seem like it should be necessary, and I'm not sure I want that turned on everywhere, just yet.
Also made it seem like I might not want it on all the time.
Out of curiosity, how is it only a warning if a file format isn't recognized??
I think it's just looking for info to do optimizations at link time, but if it doesn't find what it needs (the IR), it goes ahead and uses the code generated at compile time. Ideally, if you're using -ipo/-Qipo consistently at link time and compile time, I wouldn't expect to see these messages. If you can give me a test case that shows the problem I could get a more detailed answer about what's going on (and hopefully a fix at some point).
I agree, it's not good form to be printing out warnings inappropriately, so if you can provide a test case I'd like to get to the bottom of it.
Ok. I spent a bunch of time trying to distill some of our code into a more concise example, and ended up with an entirely degenerate case, but it still produces this error. The actual code includes a number of template definitions, but no actual instantiations.
I think I've attached the files properly.
The error happens after these commands (in build.sh):
rm -rf bin
mkdir -p bin
icpc -c -xc++ -O0 -g -w1 -inline-level=0 -pthread -c -o "bin/fact.o" "fact.cpp"
#Just in case
rm -f "bin/libfact.a"
xiar rc "bin/libfact.a" "bin/fact.o"
icpc -c -xc++ -O0 -g -w1 -inline-level=0 -pthread -c -o "bin/test.o" "test.cpp"
icpc -o "bin/test" "bin/test.o" "bin/libfact.a" -lrt -g -pthread -Wl,-z,now
ipo: warning #11010: file format not recognized for bin/libfact.a, possible linker script
Good luck, and thanks for your help!
Thanks for the test case!
It looks like the problem in this case is related to the fact the created archive is basically empty. In fact, in addition to the warning you reported I see this one as well:
$ sh build.sh
xiar: executing 'ar'
ipo: warning #11053: bin/libfact.a is an archive, but has no symbols (this can happen if ar is used where xiar is needed)
ipo: warning #11009: file format not recognized for bin/libfact.a
I suspect this may be an artifact of reducing the test case, i.e. I'm assuming that the archive in the original case was not empty. Anyway, when I add a function "foo" to fact.cpp, then the problem goes away and the only output I see is the "xiar: executing 'ar'" message (not sure if that's a bug or a feature :-) I'm investigating why it gives a warning on an empty archive, but I'm wondering if your original case is something a little different?
That's interesting. When I run it, I don't get error 11053 at all; or 11009, though that seems similar to 11010. I'm using version 11.0, perhaps you're using 11.1?
As it happens, in my actual code here, the .h file contains only some template definitions, and the .cpp is empty (aside from including the header). When I just tried adding a function (or variable) definition to either file, the error 11010 goes away. I wonder why I'm not getting the "is an archive, but has no symbols" warning. It does seem like a valid use-case, though.
You're right, I'm using 11.1. When I try 11.0 I see the same output you see. It makes sense to me that we probably shouldn't be issuing that second warning ("file format not recognized", I'll let you know what I find about that case), but just out of curiosity, why bother making a .a with nothing in it? The first warning (that seems to only show up with 11.1) is actually useful because it points out that you mght need xiar.
We have some generic code for some of our internal libraries (groups of modules) to compile them and group them into .a's by feature. That way, to use it, you just need the .h's and .a's. It looks like this set is especially template heavy - some of it was only ever templates, and some of it recently became more abstracted.
However, the build system gets thrown for a loop - it's essentially all compile-time templates in .h files, so the .cpp's are empty, and there's nothing to put in the .a in this case. Other parts of the build system will probably still try to go looking for the .a, should the group be referenced, though...
Hm, I'm having a similar problem using 11.1 on Mac OS X. Hopefully I can just reply here instead of creating a very similar thread (apologies if this is considered "hijacking" on this forum).
The .a files seem to contain the appropriate data (they were created via 'icpc -ipo' and archived with 'xiar rcu '):
$ nm contrib/install/lib/*.a
I'm a little confused, you indicate that "The .a files seem to contain the appropriate data" but the output of nm you list only contains undefined references. It doesn't appear to define anything, so if that's where you were expecting to find all those _lua_* symbols, it doesn't surprise me that they are undefined. Am I missing something?
Isn't the undefined "__ildata_included" reference all you'd expect to see in the .a file when its object files were compiled with the '-ipo' flag and 'xiar' is used to make the .a archive?
Aha, this seems to be the result when you compile 32-bit object files but use the x86_64 'xiar'. I'm a bit mystified as to why there are two different 'xiar' programs. I understand that there are differences between 32-bit and 64-bit object files, but why not have a single 'xiar' which detects which kind of objects it's working with (and perhaps throws a warning when mixed object file architectures are used)?
Good point, I'll look into that and see what we can do. Does it work when you get everything compiled for the same architecture? I'm sure it doesn't work if you try to mix them. Or is it just that the xiar you were using didn't match?
Right, I'm aware that you can't mix x86_64 and x86 objects. The only thing I was doing "wrong" was using the 'xiar' from the intel64 directory instead of the ia32 directory. But this seems pointless, since both the ia32 and the intel64 'icc's are capable of spitting out ia32 or intel64 code just by using '-m32' or '-m64' flags (or the more Apple-y '-arch i386'/'-arch x86_64'). So it seems to make logical sense to use the same 'xiar' for both x86 and x86_64 builds.
I would suggest that ICC on Mac OS X should mimic Xcode 3.2's GCC behavior. On 64-bit capable machines, default to '-m64'. On 32-bit only machines, default to '-m32'. This would be trivial to implement, too. A simple #ifdef and universal build of 'icc' would be all that's required, since Mac OS X will automatically run the 64-bit version of 'icc' on 64-bit capable machines, etc.
By fixing 'xiar's weird behavior and making the above change to ICC, I would suspect that the directory structure could become much more sane (eliminate ia32/intel64 directories, put everything right in bin/).