So as of vendetta 3.2.2 we need Glibc 2.3.x now? Unfortunately i've still got 2.2.4, and Vendetta 3.2.1 worked fine...

ack same here, got 2.2.x and now I can't play at all.

The Worst has happened... So what is the deal with 2.3? I tried putting it on a short while ago and everything was brought to its knees. Seems to require a serious overhaul to work. Is it better now? Can I run both somehow? argg

(The good side would be if I have to get it to work for Vendetta, then all those updates with the same annoying problem would work as well.)

I'm in the same boat. I was planning on doing a reinstall of Gentoo, complete with gcc 3.2.2 and such this weekend anyway, but I may have to accelerate my plans a bit.

I was hoping mdk 9.0 would have fixed it. 9.1 does, but with the way it is trashing my laptop, I dare not upgrade to it yet.. arg.. If I had time I would go debian or gentoo.

So honestly, how much can change between minor versions that requires an overhaul of most linux installs? I guess it just takes one thing, but it cuts out (I'm guessing) many linux users for a while.

Just pulled glibc-2.3.2 from GNU ftp site. Compiled and installed... no probs so far.. phew! The whole compile took 11 mins... gotta love this P4 3Ghz ;) good luck to others...

Whoops! Arrrrrgh, I knew something like that would happen. I upgraded the box I use to compile the game. I'll have to get an old version of glibc on there and link against that. Luckily gentoo makes that pretty easy.

Sorry about that, guys. I'll try to get that fixed this week. I'm having other linking problems besides that which I need to clear up - 3.2.2 is using the sound/video .so's from 3.2.1 because I can't seem to get them properly linked due to a missing symbol in some static library.

Please fix it a1k0n :) Vendetta run at half the fps while running Windows than running Linux...

aawwww, so i jumped up to slackware 9 for no reason :(

aahh well, at least its done now, thats it for a while.

Icarus: glad to hear the libc upgrade went well, was kinda final when you left irc =)

asphy

Feeewwwwwwww
I also reported this bug, can't play Vendetta now
Thanks a1k0n for repairing this soon :-)

Okay. This was much more work than I thought. I've (finally) got a gcc 3.2.3 static-libgcc static-libstdc++ glibc-2.2.5 cross compiler up to speed now, so we should be in good shape for future releases. Looks like the latest symbols required are from glibc 2.1.3, so this should be fairly compatible.

Dynamic Section:
NEEDED libdl.so.2
NEEDED libz.so.1
NEEDED libm.so.6
NEEDED libc.so.6

Version References:
required from libm.so.6:
0x0d696910 0x00 05 GLIBC_2.0
required from libdl.so.2:
0x0d696911 0x00 07 GLIBC_2.1
0x0d696910 0x00 04 GLIBC_2.0
required from libc.so.6:
0x09691f73 0x00 06 GLIBC_2.1.3
0x0d696911 0x00 03 GLIBC_2.1
0x0d696910 0x00 02 GLIBC_2.0

I'll have the fix out shortly. Not fully tested yet.

This is now fixed.

Thank you! i was scared for a moment i carn't play venddeta, the wondows verstion dosn't work on my computer and i carnt upgrade to mandrake 9.1 (using 9.0)

I have a regression problem with this fix.
/dev/dsp: Device or resource busy

is back. I had this problem with one of the 3.1.x series and you fixed it pretty quick.

It seems like it's back now.

Thanks
-A

really, it shouldnt ever even try to use esound or arts, just fail with a message to slay the beast and retry.


*cough* both sounds-servers will cause a heckload of lag in audio, and neither provide any form of latency guarantee(sp?).

The problem is that a game counts on the latency to be fixed or close to that, but when using arts/esd you cannot, since it is a taskswitch outside before the hardware gets the sound.. This is very problematic in a case such as vendetta where its sheer CPU and IO hunger will give it a higher priority on some scheluders (others mark them lower, tuning issue ...)

Well, this fix didn't affect /dev/dsp. It's likely that you're using KDE (or Gnome) and artsd (or esound) is being started and hogging the /dev/dsp device. Killing artsd (or esound) before starting vendetta usually fixes this.

This is something else I would like to eventually fix by making Vendetta cooperate with arts and esound. I think there's some preexisting library available for this purpose.

yeah there is A1k0n. It's called libao and audiofile. IE use THAT and it AUTOMATICALLY determines if it should use OSS, Alsa, Arts, or esound. You can get libao here: http://www.vorbis.com/download_unix.psp and audiofile here: http://oss.sgi.com/projects/audiofile/

As far as the /dev/dsp problem... also check out the post here I think about using alsa and it's OSS compatibilty module.

I don't have esd or Artsd running.

This problem was in a previous version of the OSS sound driver, and then it was fixed.

Now it seems broken again. May or may not be the same problem.

44676 May 2 22:16 osssound.so is the current ossound.so I have in my ~/.vendetta/drivers directory.

The OSS driver hasn't changed in several versions, other than being recompiled/relinked.

In any case, "/dev/dsp: Device or resource busy" can mean two things. The first is that some other process is using /dev/dsp, and Vendetta's access to it is thus blocked. If your ~/.vendetta/errors.log has "osssound: ospace info: ..." in it, then this is NOT the case. If it doesn't, then this is what's wrong.

The second meaning is that Vendetta cannot mmap the /dev/dsp device. If you're using ALSA, there's a thread about fixing this problem on the second page of the Linux forum. If not, then it could be that your card doesn't support mmap, but it sounds like it worked at some point, and "Device or resource busy" is an awfully strange error to give for mmap. So I don't think that this is the case.