MySQL - is there no end to my pain?

I've been doing all my MySQL development on an Opteron box running Solaris 10, but the production machine is an Ultra 60, and therefore sparc architecture. Having got everything ready to roll out, I set to to build MySQL on the U60 - a simple job, or so I thought - only to have it blow up during the compile:

"history.c", line 617: warning: implicit function declaration: strunvis
"history.c", line 655: warning: implicit function declaration: strvis
"history.c", line 655: undefined symbol: VIS_WHITE
cc: acomp failed for history.c

It turns out that on sparc the macro HAVE_VIS_H was being defined in config.h, but it wasn't defined on x86, which was kinda odd. Time to go spelunking through configure to figure out what was going on. It turns out that configure was probing for the file vis.h, using the usual 'write and compile a test program' method, which was succeeding. A 'find' on the immediately obvious directory trees didn't help, so the -H compiler flag came to the rescue:

$ printf '#include <vis.h>\nint main(){}\n' > try.c
$ cc -H -c try.c

Ah. sparc has some additional instructions called the VIS instructions which are analagous to the MMX extensions on x86, and it was the header file for those that was being picked up, rather than the one that history.c was expecting. This leads rather nicely to Alan's First Rule of Configure Scripting:

Test for the symbol, not the header file.

I've had pain in this area before, early on in the development of Solaris 10 I had to fix perl's Configure. Perl's Configure is way smarter than the GNU one in that it does actually probe the symbol table of the libraries it it interested in, which is much faster and also more accurate. However the perl Configure was assuming that if it found '_foo', plain 'foo' also also existed. It even went as far as assuming that if '__foo' existed then 'foo' also existed, and that just isn't necessarily so. Fixing it proved to be an exercise in cross-platform development and remote debugging - at the same time as fixing it on Solaris I managed to break Configure on MPE/iX, and had to work with the maintainer for that platform to get it going again. It never ceases to amaze me how many platforms perl actually compiles and runs on - as I said, it's Configure is way smarter than the GNU one.

I can't really blame MySQL for this particular problem, as I guess they normally build with gcc. In the past I've spent considerable amounts of time making sure perl builds OK with our compiler, and I've also obtained some free Forte compiler licenses for the other perl developers. Not that I have any say at all in the matter, the usual disclaimers apply etc, but unbundling just Forte cc, CC, dbx and dmake and offering them for free would be really helpful to both our customers and us. Sure, we can still make money by charging for the full IDE, but I'd love if we could make those bits free. Heck, even Microsoft have realised that free compilers make good sense!

Anyway, back to my MySQL problem. I've now got to try to figure out the command-line magic I need to stop it picking up the wrong header. I've also logged a MySQL bug - the bug id is 5102.

Categories : Solaris, Tech, Work