SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Mesa is just one of those packages that need some tuning to build as 32-bit and, therefore, you'll probably be better using a dedicated compat32-SlackBuild file because build32.sh will fail miserably.
One need to force the compilation to 32 bit using 2 configure flags (--enable-32-bit --disable-64-bit), otherwise the build system picks up 64-bit asm files and tries to compile them as 32-bit code.
I'll try "--enable-32-bit --disable-64-bit". Perhaps it'll fix the "ld: i386 architecture of input file `XXXXX.o' is incompatible with i386:x86-64 output." errors I was getting. Thanks
UPDATE: But now I get another problem building mesa:
Code:
CC glcpp.o
CCLD libglcpp.la
CCLD glcpp
gmake[4]: se sale del directorio `/tmp/Mesa-9.0.1/src/glsl/glcpp'
gmake[3]: se sale del directorio `/tmp/Mesa-9.0.1/src/glsl/glcpp'
CXXLD libglslcommon.la
CXXLD builtin_compiler
/usr/lib64/../lib64/libstdc++.so: could not read symbols: File in wrong format
collect2: error: ld returned 1 exit status
I have no idea why it's trying to access /usr/lib64/ now…
Thanks
UPDATE: Courtesy Mike_M here, I appended some flags in my SlackBuild, forcing it not to look in /usr/lib64:
But something else fails when trying to access a library in /usr/lib64, but the build made more progress this time…
UPDATE: I get a "cannot find -ludev" and "skipping incompatible /usr/lib64/libudev.a when searching for -ludev" error now. It's still looking in /usr/lib64, probably because I apparently don't have a 32 bit libudev… Is that in SeaMonkey?
What's the difference between a simple 32 bit package and a '32-bit compatibility' package?
A compat32 package is just a repackaging of a normal 32-bit package stripped down to only contain libs (under usr/lib) and binaries (moved to usr/bin/32/). Header files and other content are removed relying on the fact that you probably have already installed on the system a 64-bit package of the same program including those contents which would get needlessly overwritten.
UPDATE: just read now your post, Geremia.
You need to install a compat32-package of udev, of course. You can download it from a Slackware32 mirror (under the "a" category) and run convertpkg-compat32 on it.
...Continuation of trying to run TF2 in a computer with Intel Graphic Card
What I got after trying to launch TF2 was a blank screen, but with sound, and a bunch of function dumps in the console saying they couldn't be compiled.
The actual errors were not being printed in the console, so I ran steam with MESA_GLSL=debug,log steam and was able to get the following message:
Code:
GLSL shader 10 failed to compile.
GLSL shader 10 info log:
0:2(10): error: GLSL 1.30 is not supported. Supported versions are: 1.00 ES, 1.10, and 1.20
I couldn't find any info on how to get GLSL 1.30 or if it is even possible with my current setup
UPDATE2: Seems like my graphic card is to blame https://github.com/ValveSoftware/ste...inux/issues/19 ... well somewhat to blame, because I can run on windows, but apparently the specifications for Linux are higher than on Windows
I also tried running it with MESA_GLSL_VERSION_OVERRIDE=130 but all I got was a sideways Valve Logo and than a gray screen :-D
A compat32 package is just a repackaging of a normal 32-bit package stripped down to only contain libs (under usr/lib) and binaries (moved to usr/bin/32/). Header files and other content are removed relying on the fact that you probably have already installed on the system a 64-bit package of the same program including those contents which would get needlessly overwritten.
Thanks for the explanation
Quote:
Originally Posted by 414N
UPDATE: just read now your post, Geremia.
You need to install a compat32-package of udev, of course. You can download it from a Slackware32 mirror (under the "a" category) and run convertpkg-compat32 on it.
Now I it doesn't find gallium-llvm, and nor can I find a package for that… I did find llvm and am now installing that. Perhaps that'll help.
Thanks for the help
If you want to build gallium drivers, then you need to install a compat32 package of llvm too (Slackware32 already has one under the "d" category). However, intel drivers do not run on gallium ATM, so I guess you can safely disable it.
Regarding the errors, have you forgot to specify the 2 flags "--enable-32-bit" and "--disable-64-bit" for the configure script to properly configure 32 bit asm files for building?
UPDATE: looked further to mesa 32-bit/64-bit asm detection code in configure.ac and found the following snippet:
Code:
# check for supported arches
if test "x$enable_asm" = xyes; then
case "$host_cpu" in
i?86)
case "$host_os" in
linux* | *freebsd* | dragonfly* | *netbsd*)
test "x$enable_64bit" = xyes && asm_arch=x86_64 || asm_arch=x86
;;
esac
;;
x86_64)
case "$host_os" in
linux* | *freebsd* | dragonfly* | *netbsd*)
test "x$enable_32bit" = xyes && asm_arch=x86 || asm_arch=x86_64
;;
esac
;;
sparc*)
case "$host_os" in
linux*)
asm_arch=sparc
;;
esac
;;
esac
case "$asm_arch" in
x86)
DEFINES="$DEFINES -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM"
MESA_ASM_FILES='$(X86_FILES)'
AC_MSG_RESULT([yes, x86])
;;
x86_64)
DEFINES="$DEFINES -DUSE_X86_64_ASM"
MESA_ASM_FILES='$(X86_64_FILES)'
AC_MSG_RESULT([yes, x86_64])
;;
sparc)
DEFINES="$DEFINES -DUSE_SPARC_ASM"
MESA_ASM_FILES='$(SPARC_FILES)'
AC_MSG_RESULT([yes, sparc])
;;
*)
AC_MSG_RESULT([no, platform not supported])
;;
esac
fi
AC_SUBST([MESA_ASM_FILES])
Basically, if the detected host CPU is x86_64 (that's the case on Slackware64 with multilib enabled), it looks if the "--enable-32-bit" flag is set: if so, then the 32 bit asm files are selected, otherwise the 64 bit ones are.
So, the "--enable-32-bit" flag is mandatory on Slackware64 to compile a 32 bit mesa and installing a 32 bit version of the "as" assembler (which is inside binutils) is useless in this case.
If you want to build gallium drivers, then you need to install a compat32 package of llvm too (Slackware32 already has one under the "d" category).
I did.
Quote:
Originally Posted by 414N
However, intel drivers do not run on gallium ATM, so I guess you can safely disable it.
Then I wonder why the SlackBuild has this comment, right after the ./configure:
Code:
# r300 requires llvm
# Other gallium drivers:
# galahad,i915,identity,llvmpipe,noop,nv50,nvc0,nvfx,rbug,softpipe,svga,trace
Quote:
Originally Posted by 414N
Regarding the errors, have you forgot to specify the 2 flags "--enable-32-bit" and "--disable-64-bit" for the configure script to properly configure 32 bit asm files for building?
Yes, I have both those flags, but perhaps their order matters? Currently, they're the last two flags of ./configure, but I'm gonna make them first.
Thanks
UPDATE: Nope. Making "--enable-32-bit" and "--disable-64-bit" the first flags didn't change anything. It's still looking in 64 bit lib dirs. Disabling gallium still makes it throw an "impossible to find -lgallium" error.
As already mentioned in my earlier post, it seems like you don't need to specify "--disable-64-bit" too with "--enable-32-bit". I kept it in my SlackBuild probably because an earlier version of mesa was failing to build without the "--disable-64-bit" flag.
You're right about gallium being needed for i915 (older Intel integrated chips). I was on the wrong assumption that i915 was using the classic driver infrastructure like i965 (newer Intel integrated chips, like those on the Core iX family processors).
I FINALLY got around to trying this. My system runs slackware-14.0 multilib and has an NVidia GTS 450. I followed Alien Bob's Steam Client on Slackware howto, got the 287 error segfault, opened this thread, read a few pages back until I got reminded that nvidia-driver needed to be built with the COMPAT32 option, and took care of that. From that point on, it worked exactly like the Windows version. I was playing World of Goo within a few minutes later.
Thank you to all of you how have done the hard work of making this easy, especially Alien Bob.
I FINALLY got around to trying this. My system runs slackware-14.0 multilib and has an NVidia GTS 450. I followed Alien Bob's Steam Client on Slackware howto, got the 287 error segfault, opened this thread, read a few pages back until I got reminded that nvidia-driver needed to be built with the COMPAT32 option, and took care of that. From that point on, it worked exactly like the Windows version. I was playing World of Goo within a few minutes later.
Thank you to all of you how have done the hard work of making this easy, especially Alien Bob.
I just noticed that the Linux Steam release of World of Goo is the worst version so far. The version you can buy on 2dBoy's homepage (which they're selling through the Humble Store now) has both native 64-bit and native 32-bit binaries. The version in the Humble Bundles has both 64-bit and 32-bit binaries. The version being sold on Desura is advertised as running natively on both 64-bit and 32-bit systems (this doesn't surprise me, since Desura has a 64-bit client). The Linux Steam version is 32-bit only.
If the Linux Steam client is going to be 32-bit only when other purchase options offer 64-bit binaries for the same games, then I'm going to buy from Steam only as a last resort.
I still get the same gallium error even leading out the --disable-64-bit flag…
I'm not sure if this of any help to you, but here I go anyway. When I was trying to get my intel hardware working properly (before I replaced it with Nvidia), I often built new packages. For mesa I resorted to the following changes in the Slackbuild, since I had gallium issues and I only needed intel support:
I simply had to reinstall them, when the installer detects a multilib system it installs the 32 bit parts automatically. Keep in mind that you need the 12.11 Beta for TF2.
I simply had to reinstall them, when the installer detects a multilib system it installs the 32 bit parts automatically. Keep in mind that you need the 12.11 Beta for TF2.
But it creates a stupid "testing only" watermark in the screen corner, either you need to copy the /etc/ati/signature from a release version
or run this script as root to get rid of it (this is for 64bit slack, if 32bit just change lib64 to lib)
Code:
#!/bin/sh
DRIVER=/usr/lib64/xorg/modules/drivers/fglrx_drv.so
for x in $(objdump -d $DRIVER|awk '/call/&&/EnableLogo/{print "\\x"$2"\\x"$3"\\x"$4"\\x"$5"\\x"$6}'); do
sed -i "s/$x/\x90\x90\x90\x90\x90/g" $DRIVER
done
I hope steam on linux puts some pressure on them to greatly improve the drivers in the future :P
And there seems to be already a place where they collect bugs related to steam: http://devgurus.amd.com/community/steam-linux
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.