Firebird Blog | Building Firebird 4 from source for testing
The long-awaited Firebird 4 release is drawing closer, so I thought it would be a nice idea to check it out and verify that it works with firebird_fdw (and possibly add support for new features). As part of that I thought I'd try and build Firebird from source, something I've never done before. The aim is to be able to build and start an ad-hoc instance running under my local system user on a custom port, to prevent any kind ofconflict with the existing Firebird 3.x installation, installed from standard packages.
With PostgreSQL this is fairly straightforward:
./configure --prefix=/home/wherever/builds/postgresql-13 make -s -j 4 && make install
With Firebird the process is somewhat less straightforward. The basic source installation process is documented here:
but this assumes an install on a system where another Firebird version is not already installed and running.
In particular, the normal "
./configure && make install" process will end up launching an interactive install script, which refuses to run if it detects a running Firebird instance, and requires root permission to perform the install.
After some false starts and some assistance from the firebird-devel list I was able to get a purely local install running, with the following steps:
1. Obtain the source
git clone https://github.com/FirebirdSQL/firebird.git
2. Run autogen.sh
This only needs to be run once in a newly checked-out repository:
$ ./autogen.sh AUTORECONF=autoreconf **Warning**: I am going to run `configure' with no arguments. If you wish to pass any to it, please specify them on the `./autogen.sh' command line. Running autoreconf ... autoreconf: Entering directory `.' ... (many lines of output snipped) The Firebird4 package has been configured with the following options: Raw devices : enabled Service name : gds_db Service port : 3050 GPRE modules : c_cxx.cpp Install Dir : /usr/local/firebird Now type `make' to compile Firebird4
It helpfully (!) runs
configure with the default settings, which we of course don't want.
3. Run configure with custom settings
./configure \ --prefix=/opt/firebird4 \ --oldincludedir=/opt/firebird4/include \ --with-system-editline \ --with-service-port=3051 \ --enable-binreloc
--enable-binreloc" seems to be required to enable the Firebird binaries to function outside of the expected installation location. It does appear to be enabled by default though.
--with-system-editline" is recommended to provide superior editing capability in
Note that if building on CentOS 7, you may need to add the following items:
as the system-installed packages (at least the ones on my machine) might not be up-to-date enough.
4. Build the code
Just plain "
make". This will create the installation files in the subdirectory "
5. Ensure the local system user is a member of the "firebird" group
If there's an existing Firebird installation, it will have created the "
/tmp/firebird" directory as:
drwxrwx--- 2 firebird firebird 4096 Aug 28 15:38 /tmp/firebird/
and a Firebird instance running under a different user will need to be able to write to this.
It's not clear if individual instances can use a different directory.
6. Create the SYSDBA user
cd gen/Release/firebird/ ./bin/isql examples/empbuild/employee.fdb SQL> CREATE USER sysdba PASSWORD 'masterkey';
If using the built-in "libtom*" packages, it will probably be necessary to explicitly set
LD_LIBRARY_PATH to include
gen/Release/firebird/lib/ before executing any Firebird binaries.
7. Update the configuration files
Sample configuration files are located in
gen/Release/firebird/. These will be read when manually starting Firebird from the installation files directory.
Despite having specified "
configure, the port setting will not have been modified in the sample
firebird.conf file, so it will need to be updated:
RemoteServicePort = 3051
It also seems desirable to set:
WireCrypt = Enabled
8. Start Firebird manually
$ ./bin/firebird &  7783
$ ./bin/isql localhost/3051:employee -u sysdba -p masterkey Database: localhost/3051:employee, User: SYSDBA SQL> SELECT CAST(rdb$get_context('SYSTEM', 'ENGINE_VERSION') AS VARCHAR(10)) FROM rdb$database; CAST ========== 4.0.0
Obviously this isn't the right way to go around setting up a production machine, and the process could probably be improved upon, but for ad-hoc testing it seems fine.