Installation notes
<< Command-line utilities | Firebird 2.5.3 Release Notes | Compatability issues >>
Installation notes
Warning re databases created or restored under Firebird 2.5.1
All users upgrading from Firebird 2.5.1 to a higher sub-release are strongly advised to migrate databases using gbak
backup/restore. If this is impracticable, at least rebuild all compound indices in the databases being migrated.
Databases being upgraded from older Firebird versions (ODS 11.1 and lower) or v.2.5.0 are not affected by this regression.
Installation and migration guide: The latest version of Installation and Migration Guide for Firebird versions 2.0.x and 2.1.x is still applicable to the v.2.5 series. If a copy of this document is not present in your /doc/
directory, you can download it from the Firebird website.
Some improvements have been done to solve issues that could arise with the binary installation packages.
Linux (POSIX)
The following improvements apply to POSIX installations.
Installation scripts cleanup
Alex Peshkov
- (CORE-2195): the Linux Classic installation scripts were reviewed to improve the assignment of ownership and access rights to documentation and other components.
- (CORE-2392): Cleanups of installation scripts for all active POSIX ports for Superserver and Superclassic were done to address a problem with the Guardian on these platforms.
- (CORE-2626): The startup scripts in
/etc/init.d
did not previously take into account the presence of the directories/var/run/firebird
and/tmp/firebird
on the host system. Various types of startup failures were traceable back to this deficiency.
- (v.2.5.1 CORE-3467): A silent install switch (
-silent
) was added to make install to enable a simpler installation and the ability to automate a build and tests run. With this switch, Firebird is installed without any prompts, generating a random password for SYSDBA. The random password is saved in a file at the same location as the security database,security2.fdb
.
Dedicated Firebird switches for 'configure'
Alex Peshkov
A lot of the standard configure switches for fine-tuning the installation directories on POSIX platforms do not work for Firebird.
It was close to impossible to make the standard GNU switches work without changing the defaults for them, a rigmarole that is far from obvious or easy. Instead, a set of new switches for the configure has been added to enable fine-level configuration of the locations of Firebird's files.
The ib_util
loader was also improved to make the engine work correctly with the configured layout.
Available switches
--with-fbbin executables DIR (PREFIX/bin) --with-fbsbin system admin executables DIR (PREFIX/bin) --with-fbconf config files DIR (PREFIX) --with-fblib object code libraries DIR (PREFIX/lib) --with-fbinclude C/C++ header files DIR (PREFIXinclude) --with-fbdoc documentation root DIR (PREFIX/doc) --with-fbudf UDF DIR (PREFIX/UDF) --with-fbsample examples DIR (PREFIX/examples) --with-fbsample-db examples database DIR (PREFIX/examples/empbuild) --with-fbhelp QLI help DIR (PREFIX/help) --with-fbintl international DIR (PREFIX/intl) --with-fbmisc misc DIR (PREFIX/misc) --with-fbsecure-db security database DIR (PREFIX) --with-fbmsg message files DIR (PREFIX) --with-fblog log files DIR (PREFIX) --with-fbglock guardian lock DIR (PREFIX) --with-fbplugins plugins DIR (PREFIX)
Detection of path to Firebird's binaries
Adriano dos Santos Fernandes
Tracker reference: CORE-2398).
A feature has been implemented for POSIX builds, to have Firebird correctly detect the path where its binaries are installed.
Important: This is an experimental state currently and is disabled in the distributed binaries. To activate it, build Firebird from source and pass --enable-binreloc
to autogen.sh
when building.
Windows
Deployment structure for Embedded
Adriano dos Santos Fernandes Vlad Khorsun
Tracker entry: CORE-1814
In this release it is possible to be a little more flexible about the location of your embedded application components than previously. Changes made here addressed a handful of interrelated issues that had been problematical for application developers, viz.
- An external function library that depended on another DLL, such as
ib_util.dll
or the client code infbembed.dll
or some totally external library, could not be just placed in the..\UDF
folder beneath the emulated Firebird root (<root>
) because the depended-on files should not be in that location. It was necessary to be somewhat creative with thevariable.
- The previous rules for determining the emulated
<root>
requiredfbembed.dll
(renamed or not) to be in the same folder as the application code. One effect of that was to make it necessary either to keep separate copies offbembed.dll
for each application that needed to use it, or to place all of the client executables in one location.
Determination of the <root>
for the embedded v.2.5 engine has been changed so that it no longer has to be the application's path. It is by the location of fbembed.dll
, wherever it might be located. This means that, with the v.2.5 engine, you can set up a standard, self-contained structure for the emulated Firebird <root>
that is available to any of your embedded applications, to third-party UDF libraries and to local copies of the command-line tools, once they have loaded fbembed.dll
.
If you separate the emulated Firebird tree from your application[s], be sure to set the RootDirectory
parameter in the structure's firebird.conf
file to point to the absolute path location that is its <root>
.
Note: The new rules do not break your existing embedded structures. You can still structure your embedded applications just as you did previously. The difference now is that it is not a requirement any more to deploy your executable with its own dedicated copy of an emulated Firebird <root>
structure.
Managing MSCV8 assemblies
Vlad Khorsun
Tracker entry: CORE-2243.
Note: Because the changes took effect from v.2.1.2, this discussion also appears as a special topic in the v.2 Installation and migration document.
Firebird 2.5 is built by the Microsoft MSVC8 compiler in Visual Studio 2005. Because all the Firebird binaries are built to use dynamic linking, they all require run-time libraries.
To avoid the dll-hell issue Microsoft introduced new rules for the distribution of components that may be shared by multiple applications. From Windows XP forward, shared libraries - such as the Visual C++ and Visual C runtimes msvcp80.dll
, msvcr80.dll
and mscvcm80.dll
- must be distributed as shared or as private assemblies.
- The Microsoft MSI Installer installs shared assemblies into the common special folder SxS for use by multiple applications.
- Private assemblies are distributed with applications and should be put into the application folder. Use of the
\system32
folder for assemblies is now prohibited on the XP, Server2003 and Vista platform families.
Installing runtimes as a shared assembly
To install the runtimes as a shared assembly, the deployment system must have MSI 3.0 installed and the user must have administrative privileges. Often, this is not possible with an application being deployed with Firebird Embedded: it must be installed ready-to-run. In that case, do not plan to install the runtimes as a shared assembly.
Installing runtimes as a private assembly
To install the MSVC8 run-time libraries as a private assembly its contents - the three DLLs mentioned above and the assembly's manifest file, Microsoft VC80.CRT.manifest
- must be put into every folder where a dependent binary (.exe
or .dll
) resides, because of built-in checks for the folders that are the expected location of the runtimes that are equivalent to the compile-time libraries that were used.
A typical installation of Firebird Embedded would thus require three complete copies of the MSVC8 run-time assembly: one in the application folder and one each into the \intl
and \udf
folders. To avoid the issue of bloating the installation, some changes were done for v.2.1.2 in the way some of the Firebird binaries are built. (See also Tracker entry CORE-2243).
These are the changes that enable Firebird Embedded to work even if the application structure does not incorporate the MSVC8 runtime assembly:
a. The libraries ib_util.dll
, fbudf.dll
, ib_udf.dll
, fbintl.dll
are built without any embedded manifest. The effect is to avoid having the loader search for a MSVC8 assembly in the same folder as corresponding DLL. For this to work, the host process must have already loaded the MSVC8 run-time via manifest before any attempt is made to load these secondary DLL's.
b. fbembed.dll
now has code to create and activate the activation context from its own manifest before loading any secondary DLL that might be required.
Notes:
a. It is highly recommended to use the Microsoft redistribution package to install the MSVC8 run-time! The executable installer vcredist_x86.exe
or vcredist_x64.exe
(as appropriate to your kit selection) should be present in the zip kits for the full installation and the Embedded version. If not, it can be downloaded from the Microsoft download site.
b. Third party UDFs must satisfy one of the following requirements if a MSVC8 run-time assembly is installed as private assembly. When compiling the UDF library, the MSVC8 runtime EITHER:
- is NOT used,
- is used but the build is done without the embedded manifest,
- is used and the build is done with the embedded manifest—the default option in the MSVC IDE. In this case the MSVC8 assembly must be in the same folder as the UDF library.
back to top of page
<< Command-line utilities | Firebird 2.5.3 Release Notes | Compatability issues >>