Compiler - 32bit or 64bit?

Hi Gurus,

I need to check whether the compiler installed in my system supports 64bit compilation.

Server - Sun fire v490
OS - Solaris 5.9
Processor - Sparcv9 (64bit)
Install Directory - /opt/SUNWSpro
Compiler Model - Sun Forte C Compiler.

My development team is claiming that there are no files in /opt/SUNWspro/bin/sparcv9 directory.
Hence it doesn't support 64bit.

Can somebody help me out?

Thanks
HG

$ echo "void foo(){}" >/tmp/foo.c
$ /opt/SUNWspro/bin/cc -c -m64 foo.c -o /tmp/foo.o
$ file /tmp/foo.o
/tmp/foo.o:	ELF 64-bit LSB relocatable AMD64 Version 1
$ ls -lL /opt/SUNWspro/lib/amd64
total 44
lrwxrwxrwx   1 root     root          33 juil. 28  2009 debugging.so -> ../../prod/lib/amd64/debugging.so
lrwxrwxrwx   1 root     root          21 juil. 28  2009 libblacs_openmpi.so -> libblacs_openmpi.so.1
lrwxrwxrwx   1 root     root          42 juil. 28  2009 libblacs_openmpi.so.1 -> ../../prod/lib/amd64/libblacs_openmpi.so.1
lrwxrwxrwx   1 root     root          20 juil. 28  2009 libcollectorAPI.so -> libcollectorAPI.so.1
lrwxrwxrwx   1 root     root          41 juil. 28  2009 libcollectorAPI.so.1 -> ../../prod/lib/amd64/libcollectorAPI.so.1
lrwxrwxrwx   1 root     root          14 juil. 28  2009 libCrun.so -> ./libCrun.so.1
lrwxrwxrwx   1 root     root          37 juil. 28  2009 libCrun.so.1 -> ../../prod/usr/lib/amd64/libCrun.so.1
lrwxrwxrwx   1 root     root          37 juil. 28  2009 libCstd.so -> ../../prod/usr/lib/amd64/libCstd.so.1
lrwxrwxrwx   1 root     root          37 juil. 28  2009 libCstd.so.1 -> ../../prod/usr/lib/amd64/libCstd.so.1
...

I got the below output

Old compiler releases were requiring a different option, try:

/opt/SUNWspro/bin/cc -c -xarch=v9 foo.c -o /tmp/foo.o
file /tmp/foo.o

-m64 ist the gcc option for 64 bit. The corresponding option for the Sun Studio compiler is -xarch=v9.

Try:

/opt/SUNWspro/bin/cc -c -xarch=v9 foo.c -o /tmp/foo.o

-m64 is used too with current Sun C compilers:

Hi jlliagre & hergp,

I got the below output. Can i conclude that the compiler supports 64bit compilation?

 
[!]root: /opt/SUNWspro/bin/cc -c -xarch=v9 /tmp/foo.c -o /tmp/foo.o
 @ /
[!]root: file /tmp/foo.o
/tmp/foo.o:     ELF 64-bit MSB relocatable SPARCV9 Version 1
 @ /

Thanks
HG

---------- Post updated at 05:32 PM ---------- Previous update was at 05:28 PM ----------

Hi Jlliagre and hgerp,

I meant to say, i am concluding that it is supporting 64bit compilation....Thanks for your valuable inputs.

HG

You are welcome, Hari_Ganesh.

Thanks jlliagre for the update on cc options.

Hi Gurus,

I thought the issue was resolved,but i am stumped again.

My Dev team is still behind me with the following issue:

 
Hi,
 
Could you please check with sun, if there is 64 bit CC available for both sun solaris x-86 and sparcv9. Both the servers that we checked has 64 bit libraries, but CC and other related bin is only of 32 bit. Please check and let us know as early as possible.
 
Even if we set compiler flags as -m64 or -xarch=sparcv9. As the CC or related binaries are of 32 bit, if we override them to link with a 64 bit libray, they fail to locate them. They internally get mapped with the path of 32 bit libraries and throw wrong ELF class error, while getting linked with our libraries.
 
X-86
cheux321 @ /ist/dndev
[446]dndev: file /opt/sunstudio12.1/bin/CC
/opt/sunstudio12.1/bin/CC:      ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, stripped
 
Ultra-sparc
cheux402 @ /oasis/dndev
[175]dndev: file /opt/SUNWspro/bin/CC
/opt/SUNWspro/bin/CC:   ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, stripped
 
We have 64 bit ld available in both the servers. Likewise, please check if there is any similar patch available with sun for CC and related binaries also.
 
cheux321 @ /ist/dndev
[448]dndev: file /usr/ccs/bin/amd64/ld
/usr/ccs/bin/amd64/ld:  ELF 64-bit LSB executable AMD64 Version 1, dynamically linked, stripped
 
cheux402 @ /oasis/dndev
 [178]dndev: file /usr/ccs/bin/sparcv9/ld
/usr/ccs/bin/sparcv9/ld:        ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, stripped 

Their question is that there is no 64 bit CC binary in the said path while as there are 64 bit library files(as the above otput . This is what i understood from the meeting i had.
I was not sure about how to proceed apart from logging a case with Sun.

Any inputs is appreciated.

HG

What case would it be ?

There is absolutely no relationship between the compiler itself being 32 or 64 bit and its ability to create 32 or 64 bit binaries.

Hi Jlliagre,

Thanks jlliagre for clarifying that there is no diparity in "CC" binary for 32bit and 64 bit compilation.

Thanks Again..

Hi jlliagre,

I am back again...(Sorry i don't have anybody else to resort to)...

My problem now is(ofcourse my dev team)....They have illustrated a scenario which is explaining their issue...Would really appreciate if you could find a solution.

 
A simple scenario:
 
In C++ it is desirable to inline (feature of C++) as many codes as possible to reduce the run-time overhead of CPU intensive applications. iropt component is the global optimizer in Sun Studio compiler collection suite; and inlining will be taken care by iropt. 
 
Like CC, iropt is also a 32 bit binary in our compiler, so when initiated it throws an error like this:
 
[422]dndev: iropt -help
ld.so.1: iropt: fatal: /usr/lib/amd64/libdemangle.so.1: wrong ELF class: ELFCLASS64
Killed
cheux321 @ /ist/dndev
[427]dndev: file /opt/sunstudio12.1/prod/bin/iropt
/opt/sunstudio12.1/prod/bin/iropt:      ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, stripped
cheux321 @ /ist/dndev
[431]dndev: file /usr/lib/amd64/libdemangle.so.1
/usr/lib/amd64/libdemangle.so.1:        ELF 64-bit LSB dynamic lib AMD64 Version 1 [SSE CMOV], dynamically linked, not stripped, no debugging information available

I think their problem is that they are not able to override the 32bit libraries even after using the prescribed options. The "CC" binary (compiled in 32bit) is referring to 32bit libraries even if they specify the 64bit libraries.

Thanks
HG

Wow. Talk about taking something really, really simple and going out of their way to make it harder than it has to be.

These guys are supposed to be smart enough to write C/C++ code? But they can't get a simple compiler suite to work for them? Despite the fact that thousands upon thousands of people have that very compiler suite work just fine for them every day of the year? And they all can use that compiler suite to produce 32- and 64-bit binaries without any problems?

How'd they get iropt to barf like that? Mess around with LD_LIBRARY_PATH? If they're going to mess around with linker environment variables, sit them down and have them read and heed the man page for ld.so.1.

Hi,

Thanks for responding.You just wrote what i had in mind. Alas!I can't direct the same to my Dev team. This issue will get resolved only if i find a solution for it.

Thanks
HG

It seems you are hitting a bug fixed in a later version:
Sun Studio C++ - iropt never completes

Hi Jlliagre,

I had a session with my Dev team again to understand the issue.

Their issue is that the Folder-/opt/SUNWspro/WS6U2/bin/sparcv9 which holds the 64bit binaries contain only two binaries - "dbx" and "ild".

While as the Folder-/opt/SUNWspro/WS6U2/lib/v9 which holds the 64bit libraries contain a lot of libraries.

My Dev team's issue can be resolved if the "bin" folder can be populated with 64bit binaries like "CC","iropt" and a lot others for which there is a corresponding 64bit library in lib folder.

If any of you guys have /opt/SUNWspro/ installed on a SPARC machine,i would appreciate if you can check and confirm whether there is a 64bit binary for "CC" in folder specified above.

Note - The Dev team has clarified that when they use the 32bit"CC" to refer to 64bit lib files,the wrong ELF class error is triggered. There solution is a "64bit compiled "CC".

Would appreciate if any of you can share any knowledge on this.

Note- I hope i have not confused everybody.

Thanks
HG

I believe your dev team is wrong in their conclusions. A 32 bit CC is perfectly able to build 64 bits binaries, acting as some kind of a cross compiler.

You might hit a bug though and then should either contact your support or upgrade to a current release.

If you want this to be discussed further here, better to provide a reproducible use case with all steps.

Write a short test program:

file.c

#include <stdio.h>
int main( int argc, char **argv )
{
#ifdef _LP_64
    printf( "64-bit!\n" );
#else
    printf( "32-bit!\n" );
#endif
    return( 0 );
}

Compile it, but DON'T mess around with any environment variables, that's completely unnecessary:

cc -g -xarch=v9 file.c -o test64
cc -g file.c -o test32

Then run both binaries. Examine them with the "file" utility. Note that one is 32-bit, and the other is 64-bit.

Ask them what the problem is.

Or do they really think the entire rest of the world is failing to create 64-bit binaries using Sun Studio?

---------- Post updated at 11:54 AM ---------- Previous update was at 11:47 AM ----------

WS6U2 is ancient. Upgrade it. Upgrades are free. Just be aware you can't go past Sun Studio 11 if you're still on Solaris 8.

As for their problems getting the wrong libraries, have them produce the output of this command, from the same terminal they're having the issues compiling:

env | grep LD

I strongly suspect they have a lot of junk in their LD_LIBRARY_PATH. They should have NOTHING in any LD-type environment variables that points into the compiler suite installation.

They're thinking WAY too much about this.

achenle: they (maybe) are having an issue with CC, the C++ compiler, not cc.

So replace "cc" with "CC" in the compile command.