64b/32b library problems
good day all ... i'm trying to build a simple perl module gd.pm. looks like gcc cannot use the 32b XFree libraries: LD_RUN_PATH="/usr/lib64:/usr/X11R6/lib" cc -shared -L/usr/local/lib64 GD.o -o blib/arch/auto/GD/GD.so -L/usr/lib64 -L/usr/lib/X11 -L/usr/X11R6/lib -L/usr/X11/lib -L/usr/local/lib -lgd -lpng -lz -lfreetype -ljpeg -lm -lX11 -lXpm /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.1/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.so when searching for -lX11 /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.1/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.a when searching for -lX11 /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.1/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/X11/lib/libX11.so when searching for -lX11 /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.1/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/X11/lib/libX11.a when searching for -lX11 /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.1/../../../../x86_64-suse-linux/bin/ld: cannot find -lX11 collect2: ld returned 1 exit status where: mus:~/.cpan/build/GD-2.12 # file /usr/X11R6/lib/libX11.so.6.2 /usr/X11R6/lib/libX11.so.6.2: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped i played a little with trying: make CC="cc -m32" with the same results. i must be missing something simple here. is there a sane way to work around this issue? -- michael
Michael Galloway
i played a little with trying: make CC="cc -m32" with the same results. i must be missing something simple here. is there a sane way to work around this issue?
Yeah, as we already found out you missed to use the 32-bit libs. But seeing your problem I still have some questions to discuss. The issue is the compatibility for running 32-bit binaries on the x86_64 architecture. We have some customers out there that have binaries for i386 already and they are not able to compile the source (maybe they don't even have the source for that app) and they are concerned about that issue. Yesterday I tried something out since I got notes about low performance when running a SPECViewPerf in "32-bit". I tried the following things: 1. Compiling SPECViewPerf 7.1.1 on another machine that is running SuSE 9.0 on an i386 platfrom. Then I copied the binary file to the AMD machine and started the benchmark. The result was a "frozen" System after a while. 2. I tried to compile the benchmark on the AMD machine with the "-m32" switch, but it looked like I still got a 64-bit-binary since I wasn't able to link the things together. And linking to the 64bit version of the X11-library resulted in a binary that runs fine as if I'm running a binary generated with all 64bit libs. (You need to modify the main Makefile a bit for that). 3. Then I managed to insert "-m32" as an option to all Makefiles in the lower directories and I guess I got a "real" 32-bit binary out of that (is there a simple way to find out what sort of binary I have?). But running this will kill the X-Server sooner or later. X-Server is "nvidia" version 1.0-5332 for AMD64. Other people seem to have managed to get a working "32bit" binary of the benchmark, but they experience low performance (ok, maybe that's software rendering since the nvidia-driver replaces also some GL libs) but others report segfaults when doing that. So the question in my mind is what will happen to a binary that is compiled for i386-SuSE (with all dependencies) and is running on the AMD64 platform. Will it run as the user expects it or do we have to expect problems? Regards Rainer -- Dipl.-Inf. (FH) Rainer Koenig Project Manager Linux Fujitsu-Siemens VP BC E SW OS Phone: +49-821-804-3321 Fax: +49-821-804-2131
* Rainer Koenig
Michael Galloway
writes: i played a little with trying: make CC="cc -m32" with the same results. i must be missing something simple here. is there a sane way to work around this issue?
Yeah, as we already found out you missed to use the 32-bit libs. But seeing your problem I still have some questions to discuss.
The issue is the compatibility for running 32-bit binaries on the x86_64 architecture. We have some customers out there that have binaries for i386 already and they are not able to compile the source (maybe they don't even have the source for that app) and they are concerned about that issue.
That shouldn't be a problem for statically linked binaries. (Or Application that import their own libs) Applications that where built on a 9.0 i386 should work as well on AMD64, as the 32bit libs are the same.
Yesterday I tried something out since I got notes about low performance when running a SPECViewPerf in "32-bit". I tried the following things:
1. Compiling SPECViewPerf 7.1.1 on another machine that is running SuSE 9.0 on an i386 platfrom. Then I copied the binary file to the AMD machine and started the benchmark. The result was a "frozen" System after a while.
2. I tried to compile the benchmark on the AMD machine with the "-m32" switch, but it looked like I still got a 64-bit-binary since I wasn't able to link the things together. And linking to the 64bit version of the X11-library resulted in a binary that runs fine as if I'm running a binary generated with all 64bit libs. (You need to modify the main Makefile a bit for that).
3. Then I managed to insert "-m32" as an option to all Makefiles in the lower directories and I guess I got a "real" 32-bit binary out of that (is there a simple way to find out what sort of binary I have?). But running this will kill the X-Server sooner or later.
file
X-Server is "nvidia" version 1.0-5332 for AMD64.
Other people seem to have managed to get a working "32bit" binary of the benchmark, but they experience low performance (ok, maybe that's software rendering since the nvidia-driver replaces also some GL libs) but others report segfaults when doing that.
I cannot tell much about nvidia drivers.
So the question in my mind is what will happen to a binary that is compiled for i386-SuSE (with all dependencies) and is running on the AMD64 platform. Will it run as the user expects it or do we have to expect problems?
It should run w/o problems (Openoffice does, Acroread does...)
Regards Rainer -- Dipl.-Inf. (FH) Rainer Koenig Project Manager Linux Fujitsu-Siemens VP BC E SW OS Phone: +49-821-804-3321 Fax: +49-821-804-2131
-- Check the List-Unsubscribe header to unsubscribe For additional commands, email: suse-amd64-help@suse.com
-- Stefan Fent SuSE Linux AG, Maxfeldstr. 5, D-90409 Nuernberg
On Wed, 18 Feb 2004 10:29:12 +0100
Rainer Koenig
Michael Galloway
writes: i played a little with trying: make CC="cc -m32" with the same results. i must be missing something simple here. is there a sane way to work around this issue?
Yeah, as we already found out you missed to use the 32-bit libs. But seeing your problem I still have some questions to discuss.
The issue is the compatibility for running 32-bit binaries on the x86_64 architecture. We have some customers out there that have binaries for i386 already and they are not able to compile the source (maybe they don't even have the source for that app) and they are concerned about that issue.
Yesterday I tried something out since I got notes about low performance when running a SPECViewPerf in "32-bit". I tried the following things:
1. Compiling SPECViewPerf 7.1.1 on another machine that is running SuSE 9.0 on an i386 platfrom. Then I copied the binary file to the AMD machine and started the benchmark. The result was a "frozen" System after a while.
2. I tried to compile the benchmark on the AMD machine with the "-m32" switch, but it looked like I still got a 64-bit-binary since I wasn't able to link the things together. And linking to the 64bit version of the X11-library resulted in a binary that runs fine as if I'm running a binary generated with all 64bit libs. (You need to modify the main Makefile a bit for that).
3. Then I managed to insert "-m32" as an option to all Makefiles in the lower directories and I guess I got a "real" 32-bit binary out of that (is there a simple way to find out what sort of binary I have?). But running this will kill the X-Server sooner or later. X-Server is "nvidia" version 1.0-5332 for AMD64.
Other people seem to have managed to get a working "32bit" binary of the benchmark, but they experience low performance (ok, maybe that's software rendering since the nvidia-driver replaces also some GL libs) but others report segfaults when doing that.
So the question in my mind is what will happen to a binary that is compiled for i386-SuSE (with all dependencies) and is running on the AMD64 platform. Will it run as the user expects it or do we have to expect problems?
Normally 95+% of all 32bit programs should work fine. A few don't like the 4GB address space or the "x86_64" architecture name, but you can work around that with linux32 or linux32 --3gb. Even Wine runs fine. Occassionally there are bugs in the emulation layer that break programs, but they have gotten quite rare now. A few things (like iptables or IPSec setup) cannot be emulated, but that is normally not hit by user programs. I run some systems with a full 32bit distribution as userland and 64bit kernel and they work fine. Also some versions of the CPU have bugs in compatibility mode. These can be all worked around by the BIOS, but some early BIOS versions didn't do that. If you get complete system hangs with 32bit programs it may be worth updating the BIOS. 3d graphics is a bit of a problem. The accelerated 3d libraries often use direct rendering, and that needs 32bit support in the kernel module to translate the ioctls and data structures for the 64bit kernel. We have that working for the Radeon with the shipped open source driver, but Nvidia and the closed source ATI driver don't have the 32bit emulation layer needed. The 32bit program running on Nvidia should just use software rendering. I'm a bit surprised that it causes instability, maybe that's a Nvidia specific bug. It's possible that it uses the GLX protocol to the local server too (which could be accelerated). In fact the 64bit Nvidia driver only comes with 64bit libraries, so it should have picked up the default Mesa 32bit libraries. Maybe the Nvidia X server doesn't like Mesa software rendering. But we cannot do anything about problems in the binary only nvidia driver, so I would recommend you talk to Nvidia about that. -Andi
participants (4)
-
Andi Kleen
-
Michael Galloway
-
Rainer Koenig
-
Stefan Fent