hi,
with Humble Bundle 3 being out I was wondering if anybody got Crayon Physics to work with openSuse 11.4 ?
it needs libtiff4 and even when cheating past that with a ln to libtiff3 it comes up with libsmpeg-0.4.so.0. Neither seem to be available, or I am not looking in the right places.
so figured maybe someone got it working here ?
thanks.
Xil
I’m having problems with this program bringing my system down and the sound not working properly, and while it is kind of neat I think I have had enough of it, and I am on maybe my third draft of this response because I keep trying to test what I’m talking about and it keeps not quitting properly, forcing a hard reboot (can’t get at a terminal with CTRL-ALT-F2, can’t kill X with a double CTRL-ALT-BKSP, can’t soft reboot with the three finger salute).
But I know what you are doing wrong. The files that you can’t link to are included in the tarball in the “lib32” directory. If you have moved stuff around, consider just unpacking again. Here’s my advice:
Short version:
Leave the tarball as you find it unpacked, and however you are launching the program, the working directory has to be the base root of the tarball.
i.e.
#!/bin/bash
CRAYON_DIR=[insert crayon directory here]
cd CRAYON_DIR
crayon #there's a launcher program in there too that might be better, as I said writing and
#testing this post has already caused a lot of hard reboots, so just consider
#this all psuedocode.
note that the launcher created with the “install_shortcuts.sh” file crashed my system.
Longer Version:
Or more precisely, the working directory has to be the directory above the “lib32” directory of the installation tarball. If you are being, umm, shall we call it, “standards compliant”, i.e. trying to get the data in /usr/local/share/crayon, the libs in /usr/local/libs/ and the executable in /usr/local/bin, I don’t know how you can get that done without disassembling and relinking, and that might not be legal I don’t know, and it would be tricky anyway. You could try to just stick the libraries from the tarball into /usr/share/lib and hope for the best though, but if it’s just a single user system that seems like overkill. Even in multiuser I would just stick it in /opt/ and be done with it I think, throwing a shellscript launcher into a bin directory for it if I wanted it in the path. Mine is sitting in my home directory, actually off of the Download directory, and I think I’m done with it anyway so I’ll probably delete it soon.
I also think I know what is going on here. I think the whole issue stems from the choice of the crayon dev to use the trick of passing relative pathnames to the linker (ld) (i.e., “-l./lib32/tiff”) during the build process. The real point of the trick is a legal one: that if you have an LGPL’d library, you can distribute it as long as you want, but you have to dynamically link to it, because if you link statically you have to GPL your code. There are technical reasons for doing this also, but I haven’t heard a convincing one. Notably, if there is a security update for one of the libraries, there is no way to alert the user of your program that he needs to update it, and anyway, I am not sure that this method of distribution inspires confidence that it will be kept updated for any substantial period of time. Anyhow, the linker looks in “./lib32/” for the libraries first, and I’m not so sure I know what it does if it doesn’t find them, but I guess it might pick them up from sonewhere else since you stated that putting in a link at libtiff.so worked.
Conclusion:
Ok, my rant is over. The sound didn’t work for me in any event, it crashed my system twice, and it’s just a physics puzzler. So I think I’m just going to delete it. But I do hope I cleared up your immediate problem.
The only real dependencies are:
libc.so.6
libgcc_s.so.1
libGLEW.so.1.5
libGL.so.1
libGLU.so.1
libm.so.6
libpthread.so.0
libQtCore.so.4
libQtGui.so.4
libSDL-1.2.so.0
libSDL_image-1.2.so.0
libSDL_mixer-1.2.so.0
libstdc++.so.6
libX11.so.6
libtiff and the others are only dependencies of the dependencies included in lib32, if you use the system versions (mv lib32 _lib32) you don’t need them. libtiff is a dependency of SDL_image, but the game doesn’t seems to use any tiff image…
But true, the game kills my X server when quitting. At least when in fullscreen…
man ld.so explains it: “The shared libraries needed by the program are searched for in the following order:…”
On Thu, 28 Jul 2011 15:16:03 +0000, Xilanaz wrote:
> with Humble Bundle 3 being out I was wondering if anybody got Crayon
> Physics to work with openSuse 11.4 ?
Got it working on my 64-bit system here with no trouble at all.
The output of
ldd launcher
In the directory it unpacked to is:
linux-gate.so.1 => (0xffffe000)
libSDL-1.2.so.0 => /home/jhenderson/crayon/CrayonPhysicsDeluxe/lib32/libSDL-1.2.so.0 (0xf7743000)
libGL.so.1 => /usr/X11R6/lib/libGL.so.1 (0xf763f000)
libGLU.so.1 => /usr/lib/libGLU.so.1 (0xf75cb000)
libGLEW.so.1.5 => /home/jhenderson/crayon/CrayonPhysicsDeluxe/lib32/libGLEW.so.1.5 (0xf7584000)
libSDL_image-1.2.so.0 => /home/jhenderson/crayon/CrayonPhysicsDeluxe/lib32/libSDL_image-1.2.so.0 (0xf7567000)
libSDL_mixer-1.2.so.0 => /home/jhenderson/crayon/CrayonPhysicsDeluxe/lib32/libSDL_mixer-1.2.so.0 (0xf750f000)
libQtGui.so.4 => /usr/lib/libQtGui.so.4 (0xf6a5a000)
libQtCore.so.4 => /usr/lib/libQtCore.so.4 (0xf67bc000)
libstdc++.so.6 => /home/jhenderson/crayon/CrayonPhysicsDeluxe/lib32/libstdc++.so.6 (0xf66d0000)
libm.so.6 => /lib/libm.so.6 (0xf66a6000)
libgcc_s.so.1 => /home/jhenderson/crayon/CrayonPhysicsDeluxe/lib32/libgcc_s.so.1 (0xf668a000)
libc.so.6 => /lib/libc.so.6 (0xf651d000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf6502000)
libdl.so.2 => /lib/libdl.so.2 (0xf64fc000)
libnvidia-tls.so.270.41.06 => /usr/lib/tls/libnvidia-tls.so.270.41.06 (0xf64fa000)
libnvidia-glcore.so.270.41.06 => /usr/lib/libnvidia-glcore.so.270.41.06 (0xf4dd8000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xf4c9b000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xf4c89000)
libjpeg.so.62 => /home/jhenderson/crayon/CrayonPhysicsDeluxe/lib32/libjpeg.so.62 (0xf4c68000)
libtiff.so.4 => /home/jhenderson/crayon/CrayonPhysicsDeluxe/lib32/libtiff.so.4 (0xf4c13000)
libz.so.1 => /lib/libz.so.1 (0xf4bfc000)
libmikmod.so.2 => /home/jhenderson/crayon/CrayonPhysicsDeluxe/lib32/libmikmod.so.2 (0xf4bb1000)
libvorbisfile.so.3 => /home/jhenderson/crayon/CrayonPhysicsDeluxe/lib32/libvorbisfile.so.3 (0xf4ba9000)
libsmpeg-0.4.so.0 => /home/jhenderson/crayon/CrayonPhysicsDeluxe/lib32/libsmpeg-0.4.so.0 (0xf4b50000)
libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0xf4a5b000)
libpng14.so.14 => /usr/lib/libpng14.so.14 (0xf4a2f000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xf49a7000)
libgobject-2.0.so.0 => /lib/libgobject-2.0.so.0 (0xf4957000)
libSM.so.6 => /usr/lib/libSM.so.6 (0xf494d000)
libICE.so.6 => /usr/lib/libICE.so.6 (0xf4932000)
libXi.so.6 => /usr/lib/libXi.so.6 (0xf4922000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0xf4917000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xf490e000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xf4908000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xf48fb000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xf48f7000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xf48c1000)
libgthread-2.0.so.0 => /lib/libgthread-2.0.so.0 (0xf48bb000)
librt.so.1 => /lib/librt.so.1 (0xf48b1000)
/lib/ld-linux.so.2 (0xf77db000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xf4890000)
libvorbis.so.0 => /home/jhenderson/crayon/CrayonPhysicsDeluxe/lib32/libvorbis.so.0 (0xf4867000)
libpcre.so.0 => /lib/libpcre.so.0 (0xf4830000)
libuuid.so.1 => /lib/libuuid.so.1 (0xf482a000)
libexpat.so.1 => /lib/libexpat.so.1 (0xf47ff000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xf47fb000)
libogg.so.0 => /usr/lib/libogg.so.0 (0xf47f3000)
As you can see, I have the 32-bit libs installed.
I didn’t have any significant trouble with it, only thing I didn’t try was seeing if it crashed my X server when exiting fullscreen.
I didn’t run fullscreen, though, because my mouse went a bit nuts (high sensitivity) fullscreen.
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
Oh I think I understanding what you mean, but in that case libsmpeg-0.4.so.0 still has to be accounted for, which was the OP’s immediate problem and one which I couldn’t find, though I am fairly certain I have all the dependencies you listed. (Except I had to junk glew-1.5 for glew-1.6, the former wasn’t setting my opengl version correctly, so I don’t have one on my system, but I’m absolutely positive libsmpeg-0.4.so.0 is not a dependency of glew.)
man ld.so explains it: “The shared libraries needed by the program are searched for in the following order:…”
Good to know, I’ll give it a look.
Edit:
Everyone else’s sound is working? I get nothing out of mine, I’m using ALSA for audio and would prefer not adding pulseaudio because that’s just another thing I would have to turn off when I started up jack, but I guess that wouldn’t be catastrophic.
smpeg is there as a dependency of SDL_mixer, to give it MP3 support. Since I don’t see any mp3 file I don’t think a SDL_mixer with MP3 support is needed…
Using the “lib32” libraries I get a “there is no soundcard” message but the sound works. With the system libraries the sound works and there is no message. I’m using PulseAudio, but shouldn’t make a big difference. The audio probably goes through SDL, so it should only depend on the SDL audio backend.
Works beautifully here (oS 11.4 KDE 4.6.5 nvidia 260.19.44) after removing:
libSDL-1.2.so.0
libSDL_image-1.2.so.0
libSDL_mixer-1.2.so.0
from the bundled …/CrayonPhysicsDeluxe/lib32/ folder and installing the -32bit packages of those in Yast.
Before that I just got the background and music, and a segmentation fault after a number or random clicks in the screen.
Nothing else was necessary, but I didn’t use the shortcut installer - I prefer to test my own command lines in a terminal to fine-tune eventual options (none in this case) and then create the shortcut with the menu editor.
All the 2nd and 3rd bundle games ran nicely in openSUSE 11.4 64-bit after some tinkering. See here for more detail.