Coro and SDL

scrottie on 2008-11-14T00:06:22

SDL loves to suck in pthread, then as soon as Perl hits a Perl_safemalloc call, it coredumps. Apparently pthread does some magic that replaces malloc() with an evil twin that likes to die and take you with it.

#0  0x402ba038 in pthread_getspecific () from /lib/libpthread.so.0
#1  0x0809e795 in Perl_safesysmalloc ()
#2  0x40551b19 in pe_sys_multiplex () from /home/knoppix/lib/perl5/site_perl/5.8
.8/i686-linux/auto/Event/Event.so

gdb stacktrace.

Even building SDL with --enable-threads=no --enable-pthreads=no isn't enough. It'll just you you with a libSDL.so with dangling references to the pthreads librarty, that SDL_Perl won't be able to link to and the other SDL libs won't be able to build against. Joy of joys. I love it when something doesn't work, so you do the obvious thing, but that doesn't work, so you go to fix that... fucking yak shaving.

The most important SDL APIs on Unix have ifdefs to work without threads, but some just plain don't. You need to disable them:

 ./configure --enable-threads=no --enable-pthreads=no --enable-audio=no --enable-timers=no

I did a --prefix=/usr also but you probably want to keep the default of /usr/local and then build other stuff explicitly against that so you don't piss apt off and never get another system update again. Speaking of broken ass shit...

Then go get SDL_ttf-2.0.9.tar.gz and SDL_image-1.2.6.tar.gz and rebuild those. Make sure they're finding (use --includedir and --libdir) and using your hobbled libSDL.so, whereever you installed it. They should find the sdl-config command and use it to pick up on the lack of -lpthread. Build and install those.

SDL_Perl uses one of those new build systems that don't work right on Linux and don't have a chance in hell of working on anything else. There are a dozen build bug reports on rt.cpan.org for the thing, and I added a new one: it installs the XS .so files in ~usr/lib/perl5/site_perl/5.*.*/i686-linux/auto/src/SDL and SDL_Perl, adding a superfluous "/src" that keeps it from being found. You'll have to cd into your Perl's lib directory, find those two SDL directories, and copy them up a level, if you have this same problem. And remember kids, writing build systems is hard, so just fuckin' use MakeMaker and spare us all the grief.

But first you need to edit Build.PL and pull out mention of SDL_mixer, SDL_net, and SDL_timer -- the same modules we removed support for in the ./configure in the SDL source. So, if you can get it to go, build SDL_Perl:

perl Build.PL
./Build
./Build install

Then go fix the miss-installed .so files... then maybe, with some luck and probably about a dozen other "how to make this crap work right" tutorials like this one, you'll have an SDL that doesn't try to bloody pull in libpthread and make your Perl blow up! Yay!

-scott

What are you using Perl+SDL for?

laburu on 2008-11-14T11:00:53

That's interesting. Not long ago, someone showed how, with a little help from SDL, Perl can be a suitable platform on which to develop a commercial-quality game. I wonder whether the trouble with SDL's thread support means that this combination falls short of its promise; indeed, I can imagine games so demanding that this issue would be a show-stopper. But what kind of application are you writing that would cost you this kind of grief? And what did the SDL maintainers have to say about what you found?

Re:What are you using Perl+SDL for?

scrottie on 2008-11-15T06:08:09

Hey. Out of some mix of (false?) modesty and other factors, I don't like to talk about what I actually do. Usually I have more room to talk about stuff but in this case, it's kind of a three way and one of the parties is shy. But if you really care, telnet to weehours.net 2000 and ask for me. Obviously I'm not going to let anyone's cat out of the bag, but I can give some background. If you care, that is.
SDL works okay as far as I know. For about anything, you can ignore the fact that SDL sucks in threads and just use POE, or Event, or write your own event loop, or use SDL's.
SDL's event loop doesn't have file watchers, and one of the requirements for this project is async communication with a server over an SSL socket. So that ain't going to fly. I can fork off waiting for mouse events in another process and then select() or use Event to watch for activity from either the mouse or the SSL socket. But I'm a Coro junkie.
It's really Coro that's touchy here, and that's to be expected as long as Coro is a module rather than a comprehensive core rework. And even then, the problem of XS is hard. Cory has to copy the C stack in and out. I have a reasonably good idea how C compilers, libc, dynamic linking, etc works, but not when it comes to threads, so I don't know why Coro and threads don't play nice together, but in this case, it looks like even loading libpthreads replaces malloc() with one that does things to the stack frame that aren't safe to do with Coro loaded. And it blows up.
The real trouble with SDL that maintainers should be notified of is the build system problems, and I filed a report. However it looks like there have been no releases since 2003. Off the top of my head. Maybe I'm misremembering. But I already said all of that in the main article. There's nothing they can be expected to do about the libs they link to (the C SDL libs) sucking in libpthread, especially since this isn't generally a problem.
The retarded thing that really makes this yak shaving is I'm supposed to be working on a bit of embedded-ish hardware (which I decided to use SDL and some XS libs I wrote to wrap the vendor's C++ libs) but I can't get their API to work right, so I'm just kind of prototyping on the x86 laptop. So, part of my motivation for making Coro work with SDL is that it frickin' works on the embedded board and I might have to/get to move development back there if the vendor get their act together.
Way more than you wanted to now? Sorry.
The board is from igamesplus.com by the way. That'll give you a clue what I'm working on here. Fun stuff.
-scott