Sun Studio Express on AMD64
I am trying to install StudioExpress-linux-2006-08.tar.bz2 on AMD64 Debian 3.1. It seems that the compiler binaries are x86, not amd64:
opt/sun/sunstudiomars/prod/bin/CC: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
Since debian is pure_amd64, would it be possible to get compilers and all other tools as AMD64 excecutables? So far, the only program that can be excecuted directly on amd64 system is opt/sun/sunstudiomars/prod/bin/amd64/dbx .
Best,
Marko
# 1
> I am trying to install
> StudioExpress-linux-2006-08.tar.bz2 on AMD64 Debian
> 3.1. It seems that the compiler binaries are x86, not
> amd64:
That's correct. All the executables are 32-bit, except for dbx, which exists in both 32-bit and 64-bit versions. (A 64-bit dbx is required to debug 64-bit programs. The main executable is 32-bit, and it launches a 32-bit or 64-bit version of itself depending on the object being debugged.)
> Since debian is pure_amd64, would it be possible to
> get compilers and all other tools as AMD64
> excecutables?
Sorry, no. We ship a single set of compilers that can generate both 32-bit and 64-bit code. The version of 64-bit Linux that we support can run the 32-bit programs without a problem. We will consider supporting systems that allow only 64-bit programs in some future release.
# 2
It is ugly, but you can try to solve this by using debootstrap to bring up an ia32 userspace somewhere in your filesystem.
Once you have done that, you can either install into the ia32 environment after a chroot (simplest approach, but makes home directories, etc. more complicated), or update the base /etc/ld.so.conf to add the ia32 /lib, /usr/lib, and /usr/X11R6/lib directories to the linker search path, symlink in ld.linux.so.2, and run ldconfig. This will basically give you an ia32 userspace. If you are lucky, that will be sufficient to run your toolchain.
It is a pain and takes some doing, but I was eventually able to get vmware (32 bit) running on a debian AMD64 only install via the latter technique.
There is some info about the chroot approach in the debian docs here:
http://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id292 205
but they do not cover the ldconfig approach.
# 3
It almost works. I have x32 root at /32 and I have added
/32/lib
/32/usr/lib
/32/usr/X11R6/lib
to ld.so.conf (and rerun ldconfig). After that
ldd /home/markov/tmp/sun/opt/sun/sunstudiomars/bin/sunCC
linux-gate.so.1 => (0x00000000)
libnsl.so.1 => /32/lib/tls/libnsl.so.1 (0x55579000)
libdl.so.2 => /32/lib/tls/libdl.so.2 (0x5558e000)
libc.so.6 => /32/lib/tls/libc.so.6 (0x55591000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x55555000)
However, when I try to compile the code, I get an error:
sunCC -v -c -xarch=amd64 -Isrc -o obj/tinystr.o src/tinystr.cpp
###command line files and options (expanded):
### -v -c -xarch=amd64 -Isrc -o obj/tinystr.o src/tinystr.cpp
### sunCC: Note: NLSPATH = /home/markov/tmp/sun/opt/sun/sunstudiomars/prod/bin/../lib/locale/%L/LC_MESSAGE S/%N.cat:/home/markov/tmp/sun/opt/sun/sunstudiomars/prod/bin/../../lib/locale/%L /LC_MESSAGES/%N.cat
/home/markov/tmp/sun/opt/sun/sunstudiomars/prod/bin/ccfe -y-o -yobj/tinystr.o -Isrc -y-fbe -y/home/markov/tmp/sun/opt/sun/sunstudiomars/prod/bin/fbe -ptb obj/tinystr.o -y-xarch=amd64 -xarch=amd64 -y-xtab -y-verbose -O0 -ptf /tmp/04691%1.%2 -ptx /home/markov/tmp/sun/opt/sun/sunstudiomars/prod/bin/CC -ptk "-v -c -xarch=amd64 -Isrc " -D__SUNPRO_CC=0x590 -Dunix -D__x86_64 -D__x86_64__ -D__amd64 -D__amd64__ -D__unix -D__unix__ -D__BUILTIN_VA_STRUCT -D__linux -D__linux__ -Dlinux -D__gnu__linux__ -D__SUNPRO_CC_COMPAT=5 -xdbggen=no%stabs+dwarf2 -I-xbuiltin -xldscope=global -instlib=/home/markov/tmp/sun/opt/sun/sunstudiomars/prod/lib/amd64/libCstd.a -I/home/markov/tmp/sun/opt/sun/sunstudiomars/prod/include/CC/Cstd -I/home/markov/tmp/sun/opt/sun/sunstudiomars/prod/include/CC -I/home/markov/tmp/sun/opt/sun/sunstudiomars/prod/include/CC/rw7 -I/home/markov/tmp/sun/opt/sun/sunstudiomars/prod/include/cc -y-comdat src/tinystr.cpp -s /tmp/ccfe.04691.0.s >&/tmp/ccfe.04691.1.err
rm /tmp/ccfe.04691.0.s
/home/markov/tmp/sun/opt/sun/sunstudiomars/prod/bin/stdlibfilt -stderr </tmp/ccfe.04691.1.err
>> Assertion: DBGGEN ERROR: FILE="../src/dbg_libdwarf.c", LINE=%46, Could not load dwarf library: libdwarf.so : libdwarf.so: cannot open shared object file: No such file or directory [DBG_GEN 5.1.18] (../lnk/dbg_dbggen.cc, line 4336)
while processing src/tinystr.cpp at line 0.
rm /tmp/ccfe.04691.1.err
If I use /32 environment (we have /home dirs bound to that chroot env. as well) then I get problems when linking with sunCC (in x86 env.).
ldd does not show any problems with it dwarf library:
ldd /home/markov/tmp/sun/opt/sun/sunstudiomars/prod/lib/libdwarf.so
linux-gate.so.1 => (0x00000000)
libc.so.6 => /32/lib/tls/libc.so.6 (0x55591000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x56555000)
As soon as I disable dwarf by -xdebugformat=stabs, the compiler seems to be working.
cheers,
marko
# 4
The libdwarf library is dlopen'ed explcitly from the lib_I_dbggen.so library.
The dbggen library is a direct dependency from the C++ front end which
is called "ccfe".
Try running "ldd" on the "ccfe" binary. There is a runtime linker bug
on Linux that will cause this same error. You can read more about it here:
http://blogs.sun.com/quenelle/entry/linux_compilers_require_a_glibc
That bug was fixed a while back, so I wouldn't expect it to still
be a problem, but it's worth checking out. Perhaps that bug is combining
with something about your nested 32-bit environment.
