(Linux) nm: X.o: File format not recognized

(Linux) nm: X.o: File format not recognized

I have recently noticed that - when compiling with icc (and ifc) - nm doesn't always neccesarily recognise the file format of resultant libraries. Specifically, we have an MPI package (MPICH 1.2.4-derived) that builds to several libraries, none of which nm is able to report on.

The distro is RH7.3 running on dual Xeons.

Confusing. Anybody else seen this?

8 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I'm confused about whether you are talking about libraries or .o files. I've run into cases where nm doesn't see a symbol which is defined in an ecc built .o, although ld has no trouble with it. When the .o is built with gcc, nm sees the symbol. I don't know that this is considered a bug; I've seen no indication whether Intel compilers are intended to work with nm.

It's the *.o's it doesn't understand. It gives a listing of the the .o's within a libX.a (as you'd expect; ar's doing nothing out of the ordinary), but for each X.o you get the message in the subject line (i.e. nm: X.o: File format not recognised) rather than it reporting the symbols. I've only seen this in libraries (not executables or individual objects) and can't reproduce it on _arbitrary_ libraries (yet), so it's clearly something to do with the build process, rather than the cmplr in isolation. Still, it's weird...

>>nm doesn't always necessarily recognize the file format of resultant libraries.

I have never faced such problem, could you please provide
more info - the commands used to build the libs, etc..


Hmm - the simplest build I could give you takes _ages_ with the necessary supporting environment. I'll try and sort out reproducer for it (or at least something somewhat smaller).

John - Just a quick sanity check. You are not using the binaries targeted to a cross platform, are you? icc would target IA32 and ecc would target Itanium.

I do not recall seeing this issue either...

Fair question, but no - they're 32-bit on a 32-bit. I was being stupid in a different way, though, so my problem has changed to the one listed below.

I am now confused as to why I can't nm the Intel shared libs themselves. It is the format of those that is not understood. Of the .so's only libguide, libguide_stats and libimf may be nm'ed. File also doesn't dig the rest (output below), so presumably the magic number isn't being recognised and the files are consequently tested for ascii-ness. I'd understand if nm gave "no symbols", but the files should be recognised surely?

bash-2.05$ file /opt/intel/compiler70/ia32/lib/*.so
/opt/intel/compiler70/ia32/lib/libCEPCF90.so: ASCII text
/opt/intel/compiler70/ia32/lib/libF90.so: ASCII text
/opt/intel/compiler70/ia32/lib/libIEPCF90.so: ASCII text
/opt/intel/compiler70/ia32/lib/libPEPCF90.so: ASCII text
/opt/intel/compiler70/ia32/lib/libPOSF90.so: ASCII text
/opt/intel/compiler70/ia32/lib/libcprts.so: ASCII text
/opt/intel/compiler70/ia32/lib/libcxa.so: ASCII text
/opt/intel/compiler70/ia32/lib/libguide.so: ELF 32-bit LSB shared object, Intel 80386, version 1, not stripped
/opt/intel/compiler70/ia32/lib/libguide_stats.so: ELF 32-bit LSB shared object, Intel 80386, version 1, not stripped
/opt/intel/compiler70/ia32/lib/libimf.so: ELF 32-bit LSB shared object, Intel 80386, version 1, not stripped
/opt/intel/compiler70/ia32/lib/libintrins.so: ASCII text
/opt/intel/compiler70/ia32/lib/libunwind.so: ASCII text

In this case, the *.so INPUT's the *.so.3 file.
You might want to check that for symbols.

$ cat libcxa.so
INPUT ( libcxa.so.3 )
$ nm libcxa.so.3|head
00020478 t .ABpositive
00020598 t .ABpositive
00020748 t .ABpositive
00020858 t .ABpositive
00020447 t .Apositive
00020567 t .Apositive
00020717 t .Apositive
00020827 t .Apositive
00020527 t .ch_sign
00020663 t .ch_sign


Leave a Comment

Please sign in to add a comment. Not a member? Join today