I just installed the Studio 12 compilers on Scientific Linux (Red Hat Enterprise 5 clone, 64-bit version) on a machine with two dual-core Opterons. I wrote a Hello World program, and the C compiler handles it OK. The C++ compiler has trouble linking the 64-bit version.

$ /opt/sun/sunstudio12/bin/CC -m32 hello.c
$ ./a.out
Hello, world!

$ /opt/sun/sunstudio12/bin/CC -m64 hello.c
/usr/lib64/libm.so: file not recognized: File format not recognized

I checked that when I use the cc compiler with -m64 -lm, it uses the same library file with no complaints. Without the -lm option, it doesn't use libm at all. That makes sense.

I havent used Sun compilers for 10 years at least, and never on Linux. Have I missed something basic?

 

 

Not basic, really, but a known problem.

C++ had a problem with default linker on RH4 not being able to grok our object files due to its own bugs.
Thats why we bring updated linker with us (prod/lib/amd64/ld or something like this) and use it in 64bit compilation.
C does not have this problem and thus does not use this linker.

Some linuxes (like RH5 or SuSE10) have recently changed its object files format which causes our "older" linker to emit this "file not recognized" message.

regards,
__Fedor.

 

 

Thanks.

Is there a workaround? It sounds as if neither linker will work in this situation.

 

 

We don't currently support RH 5 or SuSE 10, primarily due to incompatible differences. We are looking into what we can do to support them.

 

 

The following fixes this:

rm /opt/sun/sunstudio12/prod/lib/amd64/ld
ln -s /usr/bin/ld /opt/sun/sunstudio12/prod/lib/amd64/ld

I can't say whether this might introduce other problems since I didn't find the sources for the modified GNU ld in the SunStudio distribution and thus can't say what sun has changed compared to the official GNU version.

Can anyone tell me where to find these sources?

 

 

AFAIK, we did not actually change anything there, just rebuilt newer version on our build system.
Pointer to the exact version of gnu ld used to be there in README for express releases.
And you can imagine it is somewere at http://ftp.gnu.org/gnu/binutils/


As we did not test with those other linkers - neither can I. However if you take binutils newer than one we use (2.16+) you are likely to encounter problems different to ones we had with 2.15.90 ;)

Please, let us know if you have any abnormal linking issues when using newer linkers to compile with Sun C++.

regards,
__Fedor.

 

 

C++ programs that throw exceptions will not work if linked with the system linker. That is why we provide our own linker. You can use compiler options to pick up the system linker if it turns out to solve a problem without breaking something else.

We contributed the linker fixes to the linux source base, but it might be a while before the fixed linker shows up in major distros like RH and SuSE.

 

 

Well, if you submitted your changes for inclusion into upstream binutils why not just pointing to some mail archive showing the patch or putting the patch somewhere on the net? If you did so (apart from honoring the GPL) you would allow us to check whether these problems are fixed in our version of the linker and if not, we could fix it and thus actually use the compiler. The only post I could find from a sun.com mail address on the binutils list in recent time is a post from Rod Evans but that seems to be unrelated to what you are describing here.

If you don't tell us details about the problem but just say that there might be some problems with the system linker it is really not quite interesting to use your product for anything because it is likely that it generates broken code although the cause of the issue was well known but just not communicated.

I mean after doing some benchmarks on C code that would provide many opportunities for optimization that were just not used by your compiler, the fact that it turns out to be extremely difficult to get even simple information about known problems makes me wonder why we should be interested in choosing this compiler at all.

 

 

You can download the source code that corresponds to the modified
version of GNU ld provided with SUn Studio 12 from this URL:

http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=8&PartDetailId=SS12-SRCID-MAY07-G-F&TransactionId=Try

 

 

Thank you!

I will look into this one and might port your changes to the version available in modern systems.

Note that there is a space in your URL that does not belong there and must be removed in order to make the link actually work.

 

 

This is an old thread, but I remember having seen this problem, and our previously installed sunstudio12 needs the change to -/prod/lib/amd64/ld as described in this thread in order for the 'hello world' test to work with -m64. However, I can confirm that I've just repeated the test with the latest version 12 update 1 and it looks like the problem is fixed. We have CentOS 5.x, which is also now listed as a supported platform.
Out of interest, anyone know more background into the fix, and also if the patches made by Sun were applied upstream to the GNU ld?

 

 

We have upgraded gnu ld to 2.17.90 and learnt to live with gnu-ld variation of COMDAT support (machinery used by C++ compilers to handle "vague linkage").
We still patch gnu ld a little tiny bit, you can find two-liner patch at {install-dir}/prod/src/patch-intel-Linux-2.17.90 if curious enough.


Nope, this change is not yet in upstream :(

regards,
__Fedor.

 

 

Thanks for those details, Fedor. Interesting to see that SS is up to 2.17.90, whilst the Centos/RHEL 5.x binutils package is only at 2.17.50. I presume this is tied to the 2.6.18 kernel version of RHEL5, so Fedora/Ubuntu etc would have newer versions. I don't suppose there will be any compatibility issues with Centos 5 libraries that have been linked with the older ld version?