Athlon 64 + SuSE 9.0 64-bit + Torque and derivatives

#1 Shouldn't 32 bit apps run perfectly un modified with 64 bit processors?

#2 Xavier, I believe this has to be enabled in the kernel for it to work, though there may be more to it than that.

#3 This relates to gentoo but gives a bit more info on the subject (dev.gentoo.org/~brad_mssw/amd64-tech-notes.html) :

The 32bit Environment

Running 32bit Programs
YOU MUST HAVE "IA32 Emulation" TURNED ON UNDER "Executable File Formats" IN YOUR KERNEL
Many changes are in progress at the moment, and the easiest way to set up a 32bit environment is to install emulation libraries.

* app-emulation/emul-linux-x86-baselibs
* app-emulation/emul-linux-x86-xlibs

The emulation libraries will create the /emul/linux/x86 directory and install most of the appropriate libraries you will need to run pre-compiled 32bit applications. It will also create 2 symlinks, /lib32, and /usr/lib32 which point back to the proper /emul directories. It will also create a symlink in /lib to ld-linux.so.2 from /emul/linux/x86/lib/ld-linux.so.2, as the 64bit variant is known as ld-linux-x86-64.so.2.

Having those 2 packages installed should allow you to run most 32bit precompiled applications. (e.g. Java, Oracle 9i, Opera)

Compiling 32bit applications from a 64bit environment
You must first have the standard 32bit environment up and running from the previous section. Then you need to add 'multilib' to your USE= flags in /etc/make.conf and emerge or re-emerge gcc-3.3.1-r5 or higher. This will build GCC with multilib support, which will allow you to create 32bit binaries by using the -m32 CFLAGS setting. Having multilib installed should not affect 64bit compilations (though you can pass -m64 if you want to be certain for some reason).
NOTE: We strongly discourage our users from EVER adding -m32 to /etc/make.conf or using -m32 with portage in any form what-so-ever, and recommend that to do 32bit compiles, they should be by hand, and not via the portage system. Not paying attention to this could seriously mess up your dependancy structure. Don't ask us how to fix this, it's your fault.

Alternative Methods (chroot)
Since the kernel actually does the 32bit emulation, you can extract the stage1 tarball for i686 to a private directory and chroot into it (use linux32 chroot /mychrootdir , linux32 will make uname print 'uname -m' as i686 instead of x86_64), then update portage, compile the entire system as a normal x86 system, and have a complete second environment, 32bit-only inside of your 64bit sytem. Unfortunately this is extremely wasteful, as you'd end up having duplicates of the same 32bit executables, and most people only need a single application or two to work in 32bit. Also, if you wanted to use those libraries for 32bit emulation from within your 64bit environment without chrooting, you'd need to edit many .so files within your emulation usr/lib directory, as especially for libc.so, libpthread.so, and librt.so, they are not actual shared object files, but have text pointing them (ld scripts) to the real .so (like a symlink, but not). That text would try to point to your native 64bit libraries, and cause your 32bit executables to bug out when trying to load.
Please refer to Tester's original amd64 documentation at the end of this document for more information on the chroot environment.

#4 Well, I'm fairly certain that 32-bit support is compiled in by default with the SuSE 9.0 64-bit distro, since they didn't make me recompile Crossover Office, the Crossover Plugins, or WineX... just rpm'd and they worked (the Wine Rack was "designed" for SuSE 9.0 'regular', it just happens that it all also works out of the bubblewrap mailer on the 64-bit version except for Marble Blast), but I'll triple check that again just to be sure.

#5 That might be, but i don't yet have 64bit box dev/test on :)

Hopefully someone with a system will be able to be more useful.

#6 I installed Transgaming's Point2Play on my AMD64 box running 64-bit Gentoo. That part went just fine. However, when I ran the Point2Play system diagnostics, the OpenGL test failed, claiming it couldn't find OpenGL.so.1.

If you read carefully the Gentoo info posted by Dr41n0 above, you'll see that x86 emulation requires 32-bit libs. In other words, you can't link a 32-bit app against 64-bit libs (and vice versa). I am running Nvidia's 4499 AMD64 OpenGL driver on this machine, but the OpenGL libs that come with that package are native 64-bit, of course. The driver doesn't include a 32-bit compatibility-mode OpenGL.so, at least not as far as I can tell.

So until Nvidia and/or ATI supply a 32-bit OpenGL stack that functions properly on 64-bit GNU/Linux, I'm afraid we're out of luck with regards to playing Win32 games using WineX on our AMD64 GNU/Linux machines. I guess you could try installing a 32-bit Mesa OpenGL.so in the /emul directory (or whatever is the equivalent on SuSE, /usr/lib32 maybe?), but I don't think you'd get hardware acceleration.

Your other apps run just fine because they don't have a dependency on OpenGL. (I think it's pretty impressive that they actually work, it's a testament to AMD's and SuSE's engineering efforts -- emulating a 32-bit OS (Windows) in another 32-bit emulation environment (32-bit x86 Linux) on top of a 32-bit processor mode (x86) on top of a 64-bit OS (64-bit AMD64 Linux) running on a 64-bit processor.)

Anyway, since you mentoned Torque, too, one of these weekends I'm going to try compiling it for native AMD64 GNU/Linux. Based on my experience with other open source projects which use x86 assembly, I don't expect it to compile out of the box, but it shouldn't be that hard to port.

#7 On the Windows XP-64 (beta out now)...32-bit programs are run in an emulater. However, there is a 64bit SDK and compiler available (MSDN subscribers). Let me know if you have source you want recompiled for distribution or for fun/testing...Don

p.s. there are GNU C++ 64-bit compilers available...for linux as well

#8 Just tried to build Torque 1.4rc1 on Fedora Core 4 x86_64 using GCC 4. I had to define some new CPU constants and GCC4 is a bit stricter, but the first serious issue I ran into was casts from pointer to SimObjectId's (which are U32's). The SimObjectId should remain the same type to allow mixed 32/64 bit servers and clients, so I've got to look closer at whether it's going to be safe to treat pointers as unique values when truncated. For instance, in shapeImage.cc:238 an AudioProfile pointer is being cast to a SimObjectId, which is odd because it's derived from a SimObject which supports getId().

#9 Another member of my team found that the conversions between pointer and SimID are due to the pointer being overloaded based on whether the object is packed for transfer across the network.

#10 Install the gcc-compat (compat-gcc?) packages on Fedora Core, then hack the Linux makefiles to either hard code the use of g++32/gcc32 or $(CXX) $(CC) and export:

export CXX=g++32
export CC=gcc32

This worked for me.