Difference between revisions of "CompilingRHEL"
| Line 6: | Line 6: | ||
I prefer to view it as mature, stable and predictable. <tt>:-)</tt> | I prefer to view it as mature, stable and predictable. <tt>:-)</tt> | ||
I do not believe there | I do not believe there is much about this procedure which is specific to RHEL4.<br> | ||
It would probably work on any good Linux installation. | It would probably work on any good Linux installation. | ||
Revision as of 03:14, 27 February 2010
Building Inkscape on RHEL4
This page documents the process I used to build Inkscape 0.47 on Red Hat Enterprise Linux, Version #4 (RHEL4.)
Many consider RHEL4 to be an archaic operating system.
I prefer to view it as mature, stable and predictable. :-)
I do not believe there is much about this procedure which is specific to RHEL4.
It would probably work on any good Linux installation.
I performed this process on 19-FEB-2010 so this information is already out of date.
Motivation
The company I work for is not free to run the latest OS versions. We are constrained by our major application vendors. That leaves us stuck on RHEL4, which appears to come bundled with Inkscape 0.44
Meanwhile I'm watching all sorts of cool Inkscape tutorials on the web, but they use later versions.
My sys-admins would not consider an Inkscape upgrade due to the contamination issue noted below. The build process documented here avoids system installs by using a local install directory.
This is an old-school build as I download and compile source code and do not use any RPMs.
List of packages
Following is the list of packages I used. Compiling this list was no small feat and took over 15 hours. I consider it a miracle I was able to converge on a compatible set of packages and compiler.
The packages are listed here in the order in which I built them. Some packages, like gc6.8, have no dependencies and could be built at any time. The pango-1.24.5 package, on the other hand, requires cairo-1.8.8 and so must be built after the cairo package.
Not all of the packages listed here are the latest versions available at the time I performed the build. In several cases I had to back off one or two years because my compiler (gcc 3.4.4) did not like the more recent versions.
Please do not change any of these package numbers without confirming a compatible set.
Do not contaminate your computer
I recommend that you use a local installation directory instead of installing packages in the standard system directories.
When you add new files (or replace existing) files in system directories you are effectively contaminating the computer. Programs that used to work may not work any longer and you may not realize that harm has been not until the trail has grown cold. (We have all had this happen, especially on Windows; You go to run some program and it does not work any more.)
Certainly, if you are experimenting, this is the right move.
Also, you do not need sudo or the root password.
Build directory layout
Pick an empty directory in which to download and build all packages.
In addition to a separate build directory for each package, add one additional sub-directory to server as the installation point.
The package directories will be created when you de-tar the downloads.
Preparing your shell environment
The following assumes that your root build directory is "/home/me/inkscape" and that it has a sub-directory named "install" which will serve as the installation point.
- setenv INSTDIR "/home/me/inkscape/install"
- setenv CXXFLAGS "-I${INSTDIR}/include"
- setenv CPPFLAGS "-I${INSTDIR}/include"
- setenv LDFLAGS "-L${INSTDIR}/lib -lm"
- setenv LD_LIBRARY_PATH "${INSTDIR}/lib:${LD_LIBRARY_PATH}"
- setenv PKG_CONFIG_PATH "${INSTDIR}/lib/pkgconfig"
- setenv PATH "${INSTDIR}/bin:${PATH}"
Why do we need these settings?
There are package dependencies. For example, we build pango, cairo and jasper early in the build-order and they will be used to build gtk+ later in the build order. That explains CXXFLAGS(compilation flags), CPPFLAGS(more compilation flags), LDFLAGS(link flags) and PKG_CONFIG_PATH(used at link time, I guess)
I set PATH because some packages install programs in the ${INSTDIR}/bin directory. These programs are used by later packages to determine version information. Therefore, they must be found along the PATH. That is also why I recommend a rehash after building each package.
I set LD_LIBRARY_PATH for the same reason. For these programs to run they must find all required libraries, some of which were installed in the ${INSTDIR}/lib directory.
I added the math library "-lm" to LDFLAGS to work around the jasper library idiosyncrasy as noted below.
Which compiler
I used gcc version 3.4.4
How to build a package
The following procedure works for most packages, but it does not work for all of them. The exceptions are noted in sections later in this document. So, you should not build any packages until you have read this entire document.
Download the compressed tar file to the root directory.
Uncompress the file.
- gunzip xyz-1.2.3.tar.gz
De-tar the file. This will create a dedicated sub-directory in which to build the package.
- tar xvf xyz-1.2.3.tar
Change to the package directory.
- cd xyz-1.2.3
Configure the package.
- ./configure -prefix ${INSTDIR}
Compile.
- make
Install.
- make install
Update your shells program cache.
- rehash
If you want to rebuild a component you will need to do the following first:
- make clean
- make distclean
Package idiosyncrasies
Build order and dependencies
The packages must be built and installed in the documented order. When built in the documented order ./configure should not complain (and abort) about any dependency violations. See the section on ./configure later in this document.
When building jasper-1.701.0
1: By default, jasper builds to a static library, but packages which use jasper expect a shared build so an additional argument must be added to the ./configure command.
- ./configure --prefix ${INSTDIR} --enable-shared
2: The gtk configure script aborted the first time I tried it because the required jasper library could not be found, but the real problem was that the ./configure test for availability failed to link because it did not include the standard math library "-lm". So, I added -lm to LDFLAGS and then it was happy. The lesson here is to always check the config.log file for the real ./configure failure story.
When building libxml2-2.7.6
1: ./configure complains about this at the end, but it does not appear to have any significant consequences.
- /bin/rm: cannot remove `libtoolT': No such file or directory
When building libxslt-1.1.26
1: lbxsltv uses ${INSTDIR}/bin/xml2-config to determine the version of the libxml(2) library which is available. This is an executable which needs to be found along the PATH. So, the bin sub-directory of the install location has to be added to the PATH. Thus the above "setenv PATH ..."
2: ./configure complains about this at the end, but it does not appear to have any significant consequences.
- /bin/rm: cannot remove `libtoolT': No such file or directory
3: The libxsl package builds libraries and the program xsltproc. I could not get xsltproc to link, but it is not required to build Inkscape, so I edited the Makefile and removed it so that the make would complete. Note: Makefiles are made by ./configure. That is what it does.
When building inkscape-0.47
1: Surprising compilation error in one of the source files.
- document.cpp:185: error: ISO C++ forbids casting between pointer-to-function and pointer-to-object
So I hacked line 185 from this:
- reinterpret_cast<gpointer>(sp_document_reset_key),
to this:
- reinterpret_cast<gpointer>((void*)sp_document_reset_key),
Surviving ./configure
1: If ./configure tells you that it can't find a dependent package, that may not be the real problem. Always check the config.log file for the real story.
As noted above, when ./configure told me that it could not find the jasper package, a look in the config.log file revealed that the logic used to determine the existence of the jasper package involved building a little test program. That test program failed to link because it could not find symbols like pow and floor. I new these came from the math library and fixed the problem by adding "-lm" to the LDFLAGS environment variable.
2: The first time I tried to build Inkscape (6 months ago) ./configure said (something like) this:
- Dependency (gmodule-2.0 >= 2.21.1) not met.
This effort ended in frustration because I could not find the gmodule package anywhere on the web. This time I determined that gmodule is actually a library and it is provided by the glib-2.22.3 package. (At the end of the build process the install/lib directory contained 38 library files (*.so), but I had only built 22 packages.)
3: And, um, oh yes... Always check the config.log file.
The final list of library dependencies
Following is the list of dependencies for the final Inkscape executable. Note that the library versions listed in this table bear no correspondence to the package from which they were built. For example, we built libgtkmm from the package gtkmm-2.18.2, but got the library libgtkmm-2.4.so.1 This just adds to the confusion.
- libgtkmm-2.4.so.1
- libatkmm-1.6.so.1
- libgdkmm-2.4.so.1
- libgiomm-2.4.so.1
- libpangomm-1.4.so.1
- libglibmm-2.4.so.1
- libcairomm-1.0.so.1
- libgtk-x11-2.0.so.0
- libgdk-x11-2.0.so.0
- libatk-1.0.so.0
- libgio-2.0.so.0
- libpangoft2-1.0.so.0
- libgdk_pixbuf-2.0.so.0
- libpangocairo-1.0.so.0
- libpango-1.0.so.0
- libfreetype.so.6
- libfontconfig.so.1
- libgobject-2.0.so.0
- libgmodule-2.0.so.0
- libxslt.so.1
- libz.so.1
- libxml2.so.2
- libcairo.so.2
- libsigc-2.0.so.0
- libgthread-2.0.so.0
- librt.so.1
- libglib-2.0.so.0
- libpng12.so.0
- libgsl.so.0
- libgslcblas.so.0
- libm.so.6
- libgomp.so.1
- libpopt.so.0
- libaspell.so.15
- libgc.so.1
- libstdc++.so.6
- libgcc_s.so.1
- libpthread.so.0
- libc.so.6
- libdl.so.2
- libX11.so.6
- libresolv.so.2
- libpixman-1.so.0
- libexpat.so.0
- libXrender.so.1
- libSM.so.6
- libICE.so.6
- libXinerama.so.1
- libXext.so.6
My operating system
>uname -a
Linux juno 2.6.9-89.0.9.ELsmp #1 SMP Wed Aug 19 08:06:10 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
>cat /etc/issue
Red Hat Enterprise Linux WS release 4 (Nahant Update 8)
Kernel \r on an \m