Vulcan on Linux

From Jim Starkey on the Firebird Development List 9th Mar 2003

I am pleased to announce the availability of a Vulcan build for Linux. The following steps should do the trick:

1. cvs checkout vulcan
2. cd vulcan
3. chmod +x autogen.sh
4. ./autogen.sh
5. cd src
6. ./set_platform linux32
7. ./boot_build

This should build the Y-valve, engine, remote, gpre, qli, isql, gbak, the messages files, the qli help database, the security database, the config utility, and other good and valuable considerations. After the initial build is complete, it can be maintained by:

1. cd vulcan/src
2. build

When we add a new component, you will need to repeat the "set_platform linux32" step. If somebody will tell me how to get a 64bit linux that I don't have to lovingly build from scratch, I'll do a "linux64" build as well. The final linux kits will have both 32 and 64bit libraries and executables. The configuration files are designed to support hybrid systems, so mix and match is the name of the game.

To run Vulcan, you will need to do the following:

  1. Define the symbol VULCAN to point to your vulcan/install directory. If you wish, you can use FIREBIRD instead, but that will probably wreak havoc with a perfectly good running firebird.
  2. Put $VULCAN/bin in your PATH variable
  3. Put $VULCAN/bin in your LD_LIBRARY_PATH variable

I haven't yet built a remote server, gfix, or the like. Someday soon, perhaps.

If you want to link against Vulcan, the proper library is $VULCAN/bin/libfirebird32.so

Any resemblance of this build procedure and a final, production build procedure is quite unintentional. Consider this a engineering build, at best. Ann is official in charge of Vulcan builds, so cards and letters should be addressed to her. But I did all of the awful things, so be nice to her.

I haven't tested the build procedure anywhere but on a few in-house machines and a Solaris box (for solaris, substitute "solaris64" for "linux32"), but it builds on Redhat 7.2 and 8.something. I haven't cleaned the warnings out of the utilities, but I didn't put them in there, either. Well, not all of them.

You might be particularly interested in how we handled the configuration files in the build directories. Connoisseurs of fine build procedures will note that there are no databases or database links in the working directories. There's also some cute hackery to create the security database without a special engine build.

The build, as always, can be expected to change hourly. No warranties of suitability for anything in particular are made.

There is a file on the kit called VulcanRules.html containing a snapshot of a working document. Nothing in it is cast in concrete, but it does reflect our current thinking on how Vulcan may be managed going forward.