The Drunken Lizard Pub

ridcully wrote:with the OpenGL support that wraps the native driver you can even run the game at close to full speed of your primary system.

Ew, no. LOL! I mean, he can if he wants. Generally, when I build something in VBox, I bring it out to my native system to run it unless I have a specific reason to keep it in VBox.

In the meantime, you can download this file to a 64 bit Ubuntu 9 machine:
http://packages.ubuntu.com/lucid/amd64/ ... 6/download

Manually unpack the deb (with ar) and stick the requested shared library file in /lib32.
I strongly advise backing up lib32 first... this worked for me but it was a "wow, that actually worked" moment

On x86_64 the trick Bryce posted probably works fine, as most other 64 bit software will still use the normal version of libc. On 32 bits I do not advice replacing glibc, but brave souls may try it.

If not, here is the work around:

download the deb rpm or whatever of glibc 2.11.

Extract it in your home dir (or /opt or something, I will use opt as example below).
For rpms, this can be done with:

cd /opt
mkdir glibc-2.11
cd glibc-2.11
rpm2cpio glibc-2.11.1-xxxx.rpm | cpio -idmv

For debs, I forget (and I am not on my debian machine now), but I am sure it is rather trivial.

We now need to use the new loader, unfortunately, this makes eschalon forget were are its datafile, and there are no ways that I could see to configure that (hint for BW...). So we could link the eschalon data files to our linker directory (ugh..). This also requires your user can read/write this folder (chmod or chown are your friends for this).

cd /opt/glibc-2.11/lib
ln -s your-eschalon-folder/datapak .
ln -s your-eschalon-folder/launchscreenpak .
ln -s your-eschalon-folder/general.cfg .

Now try starting eschalon:
cd your-eschalon-folder
LD_LIBRARY_PATH="/opt/glibc-2.11/lib;/opt/glibc-2.11/usr/lib" /opt/glibc-2.11/lib/ld-linux.so.2 ./eschalon_book_2

This works fine for me. I may try to make things more clean/easier later. If it does not work for you, you can ask me questions, I may even answer:P

Also, for BW: please do not compile against karmic's glibc. Then people running slackware or something will complain. There is a way out of this: the effort to standardize stuff for binary software. It is called LSB. If you are releasing binary software on linux, please consider reading it. I do not agree with shifting all the blame on Blitz, even although I do not know exactly what options it offers, it can do little about making all dependencies compatible. It could warn you, but you would still have to take care of making sure your build environment is standardized (which LSB takes care of).

And use a distro that supports compiling against LSB libraries (I am unsure how good ubuntu is in this respect). I think the latest LSB is 4.0. Which means it is still on glibc 2.4. Now, various people and organizations have criticized LSB, but if we all would try to adhere to it, we would have less problems with closed-source stuff.

Anyway, my advice is: compile against glibc2.4 and it will run on most distro's shipped the last 4 years.


edit: typos.

Indeed, a compile against a non-bleeding-edge libc will help a *lot* of people, and is the way to go.

BUT!

I cannot wait that long. Had to wait too long for the 26th of May already. *veg*

So I just grabbed the latest glibc packages and installed them - as mentioned before, glibc is backward compatible, so all applications compiled against 2.10 will run with 2.11. So for me (running openSUSE 11.2) I just got the neccessary packages from Factory (a total of 8 rpms, as I also have development stuff etc.):
glibc-2.11.1-5.2.x86_64.rpm, glibc-32bit-2.11.1-5.2.x86_64.rpm, glibc-devel-2.11.1-5.2.x86_64.rpm
glibc-devel-32bit-2.11.1-5.2.x86_64.rpm, glibc-i18ndata-2.11.1-5.2.x86_64.rpm,glibc-info-2.11.1-5.2.x86_64.rpm
glibc-locale-2.11.1-5.2.x86_64.rpm,glibc-locale-32bit-2.11.1-5.2.x86_64.rpm

No trouble with that, and I can play immediately. Yippieh!
Don't know how Ubuntu is organized, but that approach should work there, too

@Obiwan - thanks, that worked and I can now run the game!


But why does it have no sound regardless of the audio setting I choose... that's a different matter, I guess Does this game keep a log somewhere? In /home/.basilisk_games I only see saves, tmp and a cfg file. I'd like to use the padsp wrapper as it was suggested in another thread, but putting "padsp ./eschalon_book_2" in the "big" command starting with LD_LIBRARY PATH results in "padsp: error while loading shared libraries: padsp: cannot open shared object file: No such file or directory".

Ironically, this is the first time in a long time I was not a first-day adopter of Ubuntu. They have started rushing certain recent releases, and I am waiting for a couple months worth of patches before switching over. I also wait because the upgrade path is just plain fail. I much prefer a fresh install.

This has turned out to be my problem as well. Running Mandriva Power Pack 2008, and the official repositries only go as far as glibc 2.6! Unless it`s recompiled under older gcc, I`m stuffed too, unless one of the unofficial reps carried the higher versions, and I`m loathe to do that, as one of the reasons I`m still running this Mandriva is that it worked perfectly. Book 1 ran like a dream on it.
Damn, back to Windoze I go. Grrrr.

Tyranthraxus, the work around I posted should work on your system as well. Just download a cooker glibc from the mirrors.

Elwro: running the pa wrapper is difficult. I can look into it but am doubtful it can work without modifying how that binary works. Why not just suspend pulseaudio for the moment?

obiwan wrote:Why not just suspend pulseaudio for the moment?

Well, I tried "killall pulseaudio", but still the game runs without any sound regardless of the sound setting.

Elwro wrote:

obiwan wrote:Why not just suspend pulseaudio for the moment?

Well, I tried "killall pulseaudio", but still the game runs without any sound regardless of the sound setting.

I can't be 100% sure since I don't use pulseaudio (it was the first thing I ripped out of my system when I installed it) but the way to temporarily disable pulseaudio I believe is to run your executable as "pasuspender --<name of executable>". So in this case it would be "pasuspender --eschalon_book_2" assuming you're running it from the directory where the exacutable is located.

Thanks, but I get the same error. When I run "pasuspender ./eschalon_book_2" it starts to run, but exits complaining about glibc. But when I put the command in the context of the bigger command starting with LD_LIBRARY_PATH, I get "pasuspender: error while loading shared libraries: pasuspender: cannot open shared object file: No such file or directory", just like with padsp.

pulse can be a nuisance. killing does not always work. Even although i do believe it brings us a better sound system in the end, the incomplete support of many apps makes it troublesome. And it works differently on different distro's.

Killing probably wont work because it respawns (there is a config file to disable that). Also in theory you can route alsa through pulse , and than sound should probably work (assuming eschalon uses alsa and not oss). But I do not know what distro you use so it is difficult to provide clear help. Google around a bit?

obiwan wrote:Killing probably wont work because it respawns (there is a config file to disable that). Also in theory you can route alsa through pulse , and than sound should probably work (assuming eschalon uses alsa and not oss). But I do not know what distro you use so it is difficult to provide clear help. Google around a bit?

Yeah, I will, but I have a hunch that the error I'm getting is due to some obvious syntactic mistake on my part. So, to make it more abstract, in my case "x" works (=runs the game but complains about glibc), but "LD_LIBRARY_PATH="y" x" does not work. I'm using Ubuntu 9.10and the option to suspend Pulse is missing from System -> Preferences -> Sound; they seem change the preferences in every version.

Will google how to suspend pulse audio in karmic later on; still, I think "killall pulseaudio" had some effect since the system would not produce any sound even when I told it to (by playing an audio CD etc.)

edit: yeah, now I remember setting the config file so that pulse audio wouldn't respawn

The thing is, we are loading eschalon through a different loader (the ld-linux). To load padsp through the normal loader and eschalon through the newer loader, well, I am not sure how to type that myself. OK...now you made me think..maybe:

padsp /home/danny/glibc/lib/ld-linux.so.2 --library-path /home/danny/glibc/lib/ ./eschalon_book_2

or

pasuspender /opt/glibc-2.11/lib/ld-linux.so.2 --library-path /opt/glibc-2.11/lib/ ./eschalon_book_2

(open a new terminal before typing this, to avoid that the LD_LIB.. sticks)

No guarantees. I am not sure it will search the normal lib path after trying opt.

obiwan wrote:The thing is, we are loading eschalon through a different loader (the ld-linux). To load padsp through the normal loader and eschalon through the newer loader, well, I am not sure how to type that myself. OK...now you made me think..maybe:

padsp /home/danny/glibc/lib/ld-linux.so.2 --library-path /home/danny/glibc/lib/ ./eschalon_book_2

Thanks again. This ran the game... unfortunately, still without sound (regardless of the setting). I also tried killing pulseaudio beforehand, no change.

pasuspender /opt/glibc-2.11/lib/ld-linux.so.2 --library-path /opt/glibc-2.11/lib/ ./eschalon_book_2

This results in "unrecognized option '--library-path'"

Still, thank you again for the effort to help me