100% native 64bit linux

Archives Forums/Linux Discussion/100% native 64bit linux

MagicalTux(Posted 2005) [#1]
Seems I was a bit unlucky for that~

I'm running a 100% native 64bit system. It does not even contain compatibility libs (however I have a 32bit chroot for a few applications which didn't compile fine on 64bit).

BlitzMax works well in 32bit, however 3D operations are not possible. Also LibGL and LibGLU aren't working.

Thanks to xlibmesa (software opengl) I could compile 3D applications, but running at a very very low fps...

So I was wondering if a 64bit-compiled linux version of BlitzMax was planned, or if I really should make another installation of Linux somewhere else just for developpement...


Mark


BlitzSupport(Posted 2005) [#2]
What are the specs of the system (hardware and OS)? Do you have 3D graphics drivers actually installed and working?


MagicalTux(Posted 2005) [#3]
Hello,

My system is :
- AMD 3200+ (64bit)
- 1Gig RAM
- nVidia 6800 GT 128MB
- 740GB total storage (4 hard drives)
- Linux 2.6.8, compiled for 64bit

The nVidia drivers tried to install the 32bit compatibility libraries for the nVidia card, but I'm not sure yet it worked properly in 32bit. 64bit applications works weel, showing 6000+ fps on glxgears (hardware accelerated 3D).


EDIT: After some checks and modifications (restarted X a few times), it seems that hardware 3D is working well in 32 and 64 bit modes.

When I run 32bit glxgears without chroot()ing it works, but with this new setup, Blitz doesn't want to compile anymore (complaining about not finding -LGL and -LGLU, when they are in patch that can be found in /etc/ld.so.conf).

So I was wondering, when BlitzMax runs LD, does it have special flags or something which makes it search only in known paths ?

-rw-r--r-- 1 root root 500608 2005-06-01 08:03 /var/chroot/ia32/usr/X11R6/lib/libGLU.so.1.3

Linking:teapot_test.debug
/usr/bin/ld: skipping incompatible /usr/lib/libGL.so when searching for -lGL
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libGLU.so when searching for -lGLU
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libGLU.a when searching for -lGLU
/usr/bin/ld: skipping incompatible /usr/lib/libGLU.so when searching for -lGLU
/usr/bin/ld: skipping incompatible /usr/lib/libGLU.a when searching for -lGLU
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/3.4.5/../../../libGLU.so when searching for -lGLU
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/3.4.5/../../../libGLU.a when searching for -lGLU
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libGLU.so when searching for -lGLU
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libGLU.a when searching for -lGLU
/usr/bin/ld: skipping incompatible /usr/lib/libGLU.so when searching for -lGLU
/usr/bin/ld: skipping incompatible /usr/lib/libGLU.a when searching for -lGLU
/usr/bin/ld: cannot find -lGLU
collect2: ld returned 1 exit status

It seems ld found a 32bit libGL, but no 32bit libGLU. However it's there :
-rw-r--r-- 1 root root 500608 2005-06-01 08:03 /var/chroot/ia32/usr/X11R6/lib/libGLU.so.1.3

And the path "/var/chroot/ia32/usr/X11R6/lib" is in ld.so.conf


Craig Watson(Posted 2005) [#4]
It does seem to be that way. With my recent sound experimentation I had to copy/link some library files for aRts from /opt/kde3/lib to /usr/lib for ld running from BlitzMax to pick them up. Using ld outside of Blitz found the files no problem, and the /opt/kde3/lib folder is in /etc/ld.so.conf.


MagicalTux(Posted 2005) [#5]
Mh ... so ld running from BlitzMax would only be able to find libraries in standard paths ?

That's probably not good~ I'll try linking libGLU to somewhere

EDIT: Even better now~


Linking:teapot_test.debug
/usr/bin/ld: skipping incompatible /usr/lib/libGL.so when searching for -lGL
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libGLU.so when searching for -lGLU
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libGLU.a when searching for -lGLU
/usr/bin/ld: skipping incompatible /usr/lib/libGLU.so when searching for -lGLU
/usr/bin/ld: skipping incompatible /usr/lib/libGLU.a when searching for -lGLU
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.so when searching for -lX11
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.a when searching for -lX11
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libXxf86vm.a when searching for -lXxf86vm
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/3.4.5/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/3.4.5/libstdc++.a when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/3.4.5/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/3.4.5/libstdc++.a when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/3.4.5/../../../../lib32/libm.so when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread
/usr/bin/ld: skipping incompatible /usr/lib/libpthread.a when searching for -lpthread
/usr/bin/ld: skipping incompatible /lib/libpthread.so.0 when searching for /lib/libpthread.so.0
/usr/bin/ld: cannot find /lib/libpthread.so.0
collect2: ld returned 1 exit status

libpthread is correctly linked around but~


Craig Watson(Posted 2005) [#6]
I actually have a 32-bit chroot and lib32 compatibility on 64-bit Kubuntu/Ubuntu.

Blitz can compile perfectly (but not run) from the chroot, after that it's just a matter of linking a few files from the chroot into lib32, and then using the following command from a terminal before launching a BlitzMax application:

export LD_LIBRARY_PATH="/lib32:/usr/lib32:$LD_LIBRARY_PATH"

This will tell the application to also look in the lib32 path for library files.

I think we should be able to get Blitz to compile and run without needing chroot to compile in-between, but because the linker doesn't seem to look outside standard paths, we can't get it working right now.