Alright, hello all,I've got a Slackware 13.0 64bit system. Slackware is not a multi-lib distro, so I've got a 32-bit Slackware install in /bits/slack32 which I can chroot into. Eschalon Book I runs great in the chroot, as do a couple other games.

I'm running a 1.6 GHz Sempron with 512MiB RAM and an Nvidia GeForce 6800. Yes, it's ancient, but it's more than powerful enough for everything I normally do (it's on the minimum system requirements edge, so I want to try the demo first).

So, Slackware 13.0 uses Glibc 2.9, so I ran into the glibc version problem. 13.1 just came out, and it uses 2.11, so I grabbed the new glibc packages and updated my chroot environment. Everything that was working in the chroot still works. Now, Eschalon Book II starts up, but I get a blank window instead of the normal startup window. I've attached a scaled down screenshot of my my desktop. I use Enlightenment 16 with an ultra-minimalist theme (no titlebars and 4 pixel wide window borders for resizing). So the weird looking box on the screen is the hung startup window after I moved it.

Essentially, the window is registered and told to draw, but nothing was drawn in it, so X picks up the background. Since EBII isn't responding to redraw attempts, the contents of the window is leftover garbage from the movement animation. (I moved the window so it would show up when I scaled my desktop down from 1280x1024 to something more forum friendly.)

Also, on the command line, I'm getting this error:
[quote]
X Error of failed request: BadAccess (attempt to access private resource denied)
Major opcode of failed request: 2 (X_ChangeWindowAttributes)
Serial number of failed request: 47
Current serial number in output stream: 48
[quote]

I see these in a lot of other applications, so it may or may not be relevant. A ctrl-C in the terminal causes EBII to exit and destroy the window. Googling on the error wasn't enlightening (it doesn't seem to be an xauth problem, which is what most other hits for this error seemed to indicate, but running 'xhost +' didn't have any effect).

Anyone else have this problem?

I'm planning on updating my chroot to Slackware 13.1 when I get my disks. If there is some sort of other library mismatch, this might clear it up. Thanks all. (If no one knows, that's Ok too. Stumping me is pretty hard.)

I'm very sorry if it's a completely newbish advice, but whenever a linux program complains about not being able to access something, I try running it as a super user. Of course, this shouldn't be mandatory in case of a game, but anyway... then again, I guess you've tried it already.

Looks like a permissions based error so I am curious if you are chrooting into the 32 bit environment after you are already in X or if you are chrooting into the 32bit environment from a TTY then doing your startx command?

chrooting in on an xterm after X is running. This hasn't been a problem with any other game. The reason for doing this, of course, is because I've got X setup and working with the 64bit binaries. I actually skipped installing the Xserver at all in my chroot (just the libraries).

It's an interesting idea.

EDIT: Also, I'm bind mounting /proc and /dev into the chroot, but not home. (Which I just tried, and it doesn't make any difference.)

Sometimes it works. In this case, X is complaining about some kind of internal permissions problem. Normally, running as root will only make X permission problems worse! But it's an easy experiment, so I tried it. No dice.

Thanks, though. I actually hadn't tried it. It can be a good test to help figure out what is wrong (it usually means some file the program needs has permissions set wrong, most of the time it's a device special file).

Got one of those nagging voices in the back of my head when I saw the screenshot.
Apart from the permissions issue, I wonder if BlitzMax has made similar assumptions about OpenGL versions, as it did with glibc?
Might be a dead-end, but how far apart are the versions on your Slackware, compared with the Ubuntu version compilation was done on?

Oh man, I hope this isn't some weird OpenGL issue, but you're right, that's the drawing library Blitz uses.

I'm using the Nvidia OpenGL libraries. I downloaded and installed them about 6 months ago, so they're from Nov/Dec 2009. There's a new version from last month, I'm going to unpack it and see what's there.

Alright. Next round. I updated my nVidia drivers, but still same problem. Looking back over the forum, it looks like bitsweep has EBII working with drivers v173.14.22.

As an observation, the missing bits all seem to be from that protected "launchpak.zip". Anybody got any thoughts as to something screwing around with reading from that, I assume you`ve tried another copy to ensure that everything extracted properly? Used to have loads of fun chasing errors, only to find the wrong protection bit was set after copying from read only media (cd).

It isn't even trying to open the launchscreenpak file. In fact, it's sleeping on a futex() call (Basilisk Wrangler, I expect this futex() call is buried three library calls deep which is called from a support function written by the Blitz guys that you never see because it's 100% behind-the-scenes).

It stats the datapak file, the launchscreenpak file, then opens the datapak file and spends a lot of time loading it. There is no open() call on launchscreenpak.

I'm going to see if I can figure out what library it is sleeping in.

FWIW, I re-downloaded it from a different download service and md5summed both versions (datapak and launchscreenpak, just to be sure). The md5sums of the two different versions matched. (Which doesn't rule out the exact same corruption happening both times, but...)

After playing with gdb a bit (and figuring out how to tell gdb where the correct libraries are), I managed to get a backtrace that looks like this:



So, it's a mess thanks to no debugging symbols anywhere, but it does seem to indicate that ebii is deadlocking itself when making a call into libX11 (which then tries to grab a mutex it, presumably, already has the lock on, oops). This also means it looks suspiciously like my assessment above: a library called by a library called by Blitz support code that is part of the behind-the-scenes compiler magic (common enough, even in compilers like gcc).

Upgrading libX11 and the libpthread-stubs packages in my chroot didn't help. It will be interesting to see what the statically linked version does.

Mutually locked calls, nested deep within subroutine?
I`m out of here!

Wonder if it`s a 64-bit thing, or a new `feature` in libx?

Think I`ll go back to the classic line from "The IT Crowd" - "Have you tried turning it off and on again?"

Yeah... It's not looking good. I'm probably going to sit on it until I get my hands on the 13.1 disks and rework my whole system. Thanks though.

I take it that this is an "out of the box" kernel, and not one you`ve recompiled specifically for that machine?

And your glibc/x11 packages seem to be concurrent, so I can`t see them raising issues with each other.
Any over-zealous monitoring software in the background? (Beginning to clutch at straws).

Ok, the kernel is custom compiled, but it's a straightforward config (just the stuff needed, nothing not, and yes, I've been tracking and compiling kernels for 10 years, so the preceding statement might[*] not be idiotic arrogance).

No software monitoring on this machine. It's a workstation and I'm the sole user, so quotas and what-have-you are all wastes of cycles.

Also, my Slackware 13.1 DVD just arrived today, so I'm going to upgrade my system. I've got a spare partition sitting around which I can install a small 32-bit root partition on, so I can try booting up in pure 32-bit mode. This might take a little while to get completely setup, but I think we're out of straws. (I'm also going to try everything with the stock kernels instead of doing my normal immediate custom compile.)

[*] for definitions of 'might' meaning 'has an extremely small chance to'