How to compile community edition of Ingres 9.2 on 64-bit openSUSE 11.1

Thanks to Dejan Lekic (Deyan) on #ingres for inspiring me to write this short “how to” on building the community edition of Ingres 9.2 on 64-bit openSUSE 11.1. Currently (2009-07-24) there is no 64-bit Linux binaries of the community edition of Ingres 9.2 available at the Ingres ESD site. Because of this, the only way to run the community edition of 64-bit Ingres version 9.2 on Linux is to build it by yourself. In this posting I shortly describe the steps to get it built on 64-bit openSUSE 11.1.

To begin with, I downloaded the ISO image of openSUSE 11.1 64-bit installation DVD, which is available at openSUSE’s download site. I then installed it simply by using the defaults proposed by the installer. Since the default installation does not include the software necessary for building software (for example a C/C++ compiler), the very first thing to do is to install some necessary packages. I prefer command line tools, so I opened GNOME Terminal, used su to switch user to root (su -) and used zypper (zypper install package) to install the following packages:

  • gcc33 (also installs cpp33, glibc-devel and linux-kernel-headers)
  • gcc33-c++ (also installs libstdc++33 and libstdc++33-devel)
  • gcc33-32bit (also installs  glibc-devel-32bit)
  • libstdc++33-32bit
  • boost-jam
  • libXerces-c-devel (also installs libXerces-c28)
  • gtk2-devel (also installs several other dependencies)
  • rpm-devel (also installs popt-devel)
  • flex

After all necessary packages had been installed, I had to create some symbolic links to make GCC 3.3 the default compiler for the system. This is because the gcc33* packages don’t create symlinks for commands cc, cpp and g++. The symlinks can be created using:

ln -sf /usr/bin/gcc-3.3 /usr/bin/cc
ln -sf /usr/bin/cpp-3.3 /usr/bin/cpp
ln -sf /usr/bin/g++-3.3 /usr/bin/g++

The build also needs both 32-bit and 64-bit version of Xerces library. The 64-bit version is already installed with the base installation, but installing 32-bit version side by side requires some special steps. You need to manually download the RPMs

and install them (in the order listed) using “rpm -i –force package.rpm“. You also need to fix 32-bit C++ linking because of a missing symlink in openSUSE’s package:

ln -sf /usr/lib/ /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3-hammer/32/

I then created a new user “ingres” for building Ingres and again used su to switch user to ingres. The source code for community edition of Ingres 9.2 (build 134) can be downloaded from the Ingres ESD site (under Community Projects / Ingres Database). After downloading the source code package under /home/ingres (ingres user’s home directory), I extracted it there using tar:

ingres@ingdev:~> tar zfx ingres2006-9.2.0-134-gpl-src.tgz
ingres@ingdev:~> cd ingres2006-9.2.0-134-gpl-src/
ingres@ingdev:~/ingres2006-9.2.0-134-gpl-src> ls
cazipxp  Kerberos5  pax  src  xerces-c-src_2_5_0

Since 9.2 is pretty old, it is necessary to make some modifications to the source code. Otherwise the build will simply fail. The changes I had to make can be downloaded as patches from You just need to apply each of them by running “patch -p0 < file.patch“.

The INSTALL file contained in the src directory gives some general instructions in building Ingres. The first thing to do is to set up the build environment:

ingres@ingdev:~/ingres2006-9.2.0-134-gpl-src> export ING_ROOT=`pwd`
ingres@ingdev:~/ingres2006-9.2.0-134-gpl-src> source src/tools/port/jam/bldenv
Ingres build environment is now set
Your ING_ROOT variable is set to /home/ingres/ingres2006-9.2.0-134-gpl-src

After the build environment had been set up, it was time for bootstrap and build:

ingres@ingdev:~/ingres2006-9.2.0-134-gpl-src> cd $ING_SRC/tools/port/jam
ingres@ingdev:~/ingres2006-9.2.0-134-gpl-src/src/tools/port/jam> jam
...found 28 targets...
...updating 5 targets...
MkDir1 /home/ingres/ingres2006-9.2.0-134-gpl-src/tools
[... some output suppressed ...]
Chmod1 /home/ingres/ingres2006-9.2.0-134-gpl-src/tools/bin/iijam
...updated 5 targets...
ingres@ingdev:~/ingres2006-9.2.0-134-gpl-src/src/tools/port/jam> mkjams
Creating $ING_SRC/tst->$ING_TST  link...
Creating $ING_SRC/bin->$ING_TOOLS/bin  link...
Building Jamfile files for: ingres
Doing MANIFEST files
[... some output suppressed ...]
tools: doing group
ING_SRC: doing top
ingres@ingdev:~/ingres2006-9.2.0-134-gpl-src/src/tools/port/jam> cd $ING_SRC

This was the final step before building Ingres. By running “jam -q”, you can start building it:

ingres@ingdev:~/ingres2006-9.2.0-134-gpl-src/src> jam -q
[... some output suppressed ...]
...updated 16316 targets...

The build is now ready. For the rest you can follow the instructions in the INSTALL file.

UPDATE 2009-07-28: It is possible to use newer GCC. At least GCC 4.1 seemed to work by simply using packages gcc41, gcc41-32bit, gcc41-c++ and libstdc++41-32bit instead of the ones listed in the beginning. Remember to make the necessary symlinks.


  1. Dejan Lekic says:

    Pauli, thanks a lot!

  2. Roy says:

    Thanks for that Pauli. It looks a slightly daunting procedure for a newbie though, and I wonder if the lack of a 64-bit 9.2 executable for Linux on ESD is just an oversight? There are executables of all other Ingres releases for 64-bit Linux there. A 9.2 executable is definitely a good idea; 9.3 and 9.4, which are there, are probably not ripe yet.

  3. boro says:

    Hi Roy! I just found out that the source code and binary packages for the community edition of 9.2 have been removed from the ESD. I have no idea why and when this has been done. Since 9.2 was the latest “stable”, there is currently no stable version of Ingres available to the community. 9.3 is still pretty buggy (at least based on Dejan’s difficulties) so I would not recommend it for anyone (expect alpha/beta testers). Not that the released community edition of 9.2 was any better — it contained a lot of critical bugs which had been fixed in the business edition ages ago. The stupid thing was that there was no place to store the fixes by the community because there was no source code repository or similar for them. All that there was, was a static snapshot of the source code and nothing to accommodate the community efforts to make 9.2 (or any other version) usable for production use.

    The situation looks a bit better for the later versions. I see that there’s tags for several builds of 9.3, 9.4 and 10.0 at People can get the source, build it and try it out. Bugs can be reported through the site and if you have a fix, it might even get included in the tree. But what happens once the 9.3 is released? Will there be a separate branch of this version at for the community efforts (bug fixes), or will it degrate into a static snapshot just like the 9.2 did? What is the plan to accommodate the development of the community editions so that they would actually get adopted in real use like MySQL or PostgreSQL? The time will show.

Submit a Comment

You must be logged in to post a comment.