So I was always annoyed by the way dlcompat
used to just leak. Then one day a couple of months ago, I said to myself “Hey, just add a call to atexit(3) and put in some cleanup code”.
I figured that it would be safe to deallocate everything then, after all we are in exit(), nothing could possibly call dlopen/dlclose/dlerror/dlsym from there right?
WRONG!
I discovered today that it is indeed possible to call dl functions after exit() has been called.
C++ static destructors can be called after I do my cleaning in dlcompat_cleanup. So, exit calls dlcompat_cleanup which deallocates all it’s malloc’d blocks and the pthread locks etc. exit then proceeds to call
the c++ static destructors which call dlclose, at which point dlcompat barfs all kinds of ugly stuff before it dies rather vocally.
So now I guss I have to go patch dlcompat to leak again. Sometimes it is better to leak
than have something squat on your head and do a big poop.
Well it has taken a little while, but I finally have a working Mac OS X 10.2 install again.
Time to get fink up to date and update my packages this week, then with a bit of luck
I will be able to help out drm and jfm with the gcc-3.3 fink updates.
I am now a libtool co-maintainer.
That is pretty cool. I get a commit if approved by another maintainer or if 72 hours pass
without comment on my patches. Beats the hell out of waiting for what certainly feels like forever for someone to commit my patches.
On the downside, of course, is that I am now one of the people that patch submitters
are going to be mad at for not committing their patches as soon as they post them to the mailing list.
I used to think that it was a relatively easy process, but it is a little harder than
I originally thought.
Got to make sure the patch does what it says, try your best to ensure it breaks nothing,
and, of course, test the thing on as many systems as possible.
No wonder it took forever for my patches to be applied.
Looks like my powerbook’s internal drive has died. I’ll be spending the next
few days either taking the machine apart and putting in a replacement drive, or
throwing the thing against the wall and getting a new one.
I hope I have fairly recent backups of the important stuff, although I’ve a
horrible feeling I’m missing my gpg key.
Okay, here is what I hope to get done to libtool over the next few days:
- Make -framework foo and -F/path work properly
- Update the documentation to reflect reality
- Change ltdl so it prefers the dyld code I added rather than any dlopen function it might find.
I don’t think I’ve said this enough, libtool is a pain.
Well, since I am going on holiday, I thought I’d better point people at a
not so crashy mysqlcc.
Download Mysql
Control Center for Mac OS X
I downloaded the mysqlcc source code, and thought I’d have a go at building
it with trolltech’s
Qt-3.2.0 (Qt/Mac Free.
Even though the page says the latest edition is 3.1.2, 3.2.0 is available for download.
Qt takes forever and a day to build on my powerbook g4, it also takes forever to build something which uses it, so most of the days was spent washing my car while the things compiled.
I did eventually get mysqlcc built, and it seems to work, but it crashes a lot while running and every time it exits. I think the exit crash has to do with the HotKey code, I’ll look at disabling that alltogether and see what happens.
If you want to have a look, you can download a 4.1Mb binary that I built today.
MD5 for the binary is: aec05d25efce0c05656a9c7a5c900212
The above link not working? Download mysqlcc/mac from this site
It was built with the 0.9.2 source release of mysqlcc and Qt/Mac Free 3.2.0.