Speedtable loading should keep going if it can't autorecompile

[Karl Lehenbauer]

If speedtables startup detects that a compiled shared library is out of date but it can't recompile the shared library due to permissions problems, it should load the old shared library instead of erroring out.

Also it might be a good idea to have a switch to allow an app to disable speedtable extension autorecompile entirely.

[Jeff Lawson]

This should probably only be done if they are out of date only because of changes in the ctable package. If the shared library is older than the user's table definitions, then it probably should still fail.

[Peter da Silva]

I mentally set this aside to think about later while I was working on the hashEntry problem, because that was tricky enough. Just came across this again while reading through my saved mail.

I think the original idea was that if you don't want to recompile the Speedtable, you would simply load the package without executing the Speedtable code. I remember we had a discussion about how Speedtables could be used in canned applications on systems where you couldn't depend on a compiler, and Karl pointed this out to me - you would simply ship the binaries and never load the Speedtable definition at all.

Jeff has a good point, though. There's a use case for checking the speed table definition only and assuming that the speedtable core itself is stable, but there's so many possibilities that it would probably be better to let the end-user create a wrapper that fits his model. I did that in CableAware for my dynamically generated speed tables... if the speedtable generated from the SQL matched the old definition closely enough, I didn't even try and compile it I just loaded the library.