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
/ws/on-tools-uk/SUNWspro/SOS8/prod/include/cc/vis.h
	/ws/on-tools-uk/SUNWspro/SOS8/prod/include/cc/sys/vis_proto.h
		/usr/include/sys/isa_defs.h
	/ws/on-tools-uk/SUNWspro/SOS8/prod/include/cc/sys/vis_define.h
	/ws/on-tools-uk/SUNWspro/SOS8/prod/include/cc/sys/vis_types.h
	/ws/on-tools-uk/SUNWspro/SOS8/prod/include/cc/sys/vis_asi.h
$

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

Three hot days and a thunderstorm

There's an old joke that says that summer in Britain consists of 'three hot days and a thunderstorm', which is exactly what has been happening with the weather over the last week, as a results of us being slapped around by the tail end of Hurricane Alex - on Tuesday we had over 100mm of rain in a day (that's over 4 inches for my colonial friends ;-). In fact only a couple of weeks ago I was out walking and the conditions were more like late October than midsummer - this shot was taken from the top of Lawrence Edge, looking west down the Longdendale reservoir chain.

Longdendale

One of the consequences of the long-standing pollution of the Dark Peak moorland is that it kills the plant cover on the moors, which exposes the bare peat underneath. When there is heavy rain the peat gets rapidly eroded and washed away, as you can see by the colour of the water going down Wildboar Clough:

Wildboar Clough

The Moors for the Future project is trying to repair over 100 years of damage and revegetate the bare peat surfaces. This is partly funded by the Water Authority who have a vested interest, both because the peat silts up the reservoirs, and because it costs money to remove the discolouration from the water.

Now that the fence around Bleaklow has been completed and this year's helicopter reseeding and liming has taken place, it's astonishing how rapidly the vegetation has recovered, especially after last year's disastrous fires. I think the major factor has been the fence, as existing grass which was cropped flat is now 30-40 cms long and covered in seed heads. I've always suspected that the real cause of the problems was largely due to overgrazing by sheep, and the way the vegetation has bounced back proves it. So much for the farming fraternity being 'The guardians of the countryside', as they are always fond of telling us! For a long time they've pointed the finger at walkers as being the cause of the erosion, but it's quite difficult to see how that could be the case - people prefer to walk along well-defined paths, and the moors suffer mostly from widespread surface denudation rather than footpath erosion, which has been reduced anyway since most of the more eroded path has been resurfaced with stone flags.

One benefit of the damp spell we've been having is it keeps everything moist, allowing things like these rather splendid fungi to grow, the big one at the back was 20cm (8") across.

Fungi

However, it hasn't been raining all the time, last weekend I took the kids out for a wander around Tintwistle Low, the picture below is looking southwards across the valley, over Valehouse reservoir and towards Glossop, which is just out of view over the hill in the foreground. - my house is about 4k (2.5 miles) away from here. The ridge on the far left skyline is the southern edge of Kinder.

Tintwistle Low

Categories : Peak District

MySQL bites my ass... again.

Having got all my data shovelled into MySQL, I foolishly decided that I'd like some of it back. I'd carefully normalised all my tables, so in order to retrieve it I needed to join across several tables plus I needed some subqueries in the select field list to do some lookups, so it ended up being a reasonably complex query - something along the lines of:

select
    a1.col1, c1.col2
    (select b1.col2 from b b1 where b1.col1 = a1.col2),
    (select b2.col2 from b b2 where b2.col1 = a1.col3)
from
    a a1 join b b3 on a1.col1 = b3.col1
    join c c1 on a1.col4 = c1.col1
order by
    b3.col4

Which worked just fine - right up until the rows where the value in a1.col3 was NULL, when instead of the second subselect returning the value NULL it returned the value looked up in the subselect on the previous line of the query!!!!! I've tried to create a smaller reproducible test case without success, and I really don't have the time to chase it down. Removing the third join on the b table makes the problem go away, but then I lose the required ordering - gah!

I can reformulate the query to remove the subselects by the crafty use of a left outer join, which will probably be more efficient anyway, but it should work as is. Bah.

I hates software!

Categories : Solaris, Tech, Work