[Plplot-general] A completely static build of a PLplot example

[Alan W. I. <ir...@be...>]

On 2006-09-21 18:44-0700 Alan W. Irwin wrote:

> The current status is the CVS version of PLplot should give a static build
> of PLplot libraries (including the C++ wxwidgets and psttf devices) that
> passes all build-tree tests, but there is still a minor problem (library
> ordering issue) for the install tree tests which I will deal with tomorrow.

That problem is now sorted out for our new CBS.

>
> Note, this PLplot "static build" is still not what Joe wants since even
> though the PLplot libraries are all statically linked together for this
> case, the external linking is still shared.  I think the solution to making
> even the external linking shared is simply to impose the -Bstatic link
> option on top of the static PLplot build (once that completely works), but I
> haven't tried that yet, and I am sure there will be minor but time-consuming
> issues to sort out.

It turned out there were a lot of those, but I finally got a completely
static build (with our new CBS) of one of the installed examples to work
with the wxwidgets device driver.

So Joe, here is the cookbook you should follow if you want a completely
static build (no external library dependencies at all) of an executable that
uses our plplot library (with embedded wxwidgets device and static linking
to all the wxwidgets related libraries). If there is any part of the
cookbook you do not understand, contact me off list.

(1) Build a static version of wxwidgets.  I don't think any distribution
does that because there is a choice of static or shared, but apparently not
both. Certainly, Debian and derivative like Ubuntu do not provide a static
version of the wxwidgets libraries.

I used wxGTK-2.6.3.tar.gz from SourceForge, and did their recommended
out-of-source build using --disable-shared (which is their option for a
static build).  I also did a shared build as well because that is what I
normally use, but I used a unique build tree and installation prefix for
that so the shared and static results could not clash with each other.

(2) Build PLplot with our new CBS.  On your Linux build system follow the
general Unix directions on our wiki (http://www.miscdebris.net/plplot_wiki).
(Those instructions include downloading and building the latest version of
cmake. That is currently 2.4.3.  Don't use a lower version than that.)

(2a) Preparation for the build using CMake.

The wiki discusses helping cmake to find system resources.  In my case I
installed the above static wxwidgets package with a unique prefix of
/usr/local/wxwidgets.  Thus, I had to set

PATH="/usr/local/wxwidgets/bin:"$PATH

That allowed cmake to find the correct (static) version of wx-config and
bootstrap all wxwidgets information from there.

Here is the cmake command-line I used to pare everything down to a minimal
PLplot system with one (wxwidgets) device:

cmake -DCMAKE_INSTALL_PREFIX=/home/software/plplot_cvs/installcmake \
-DCMAKE_VERBOSE_MAKEFILE=ON -DENABLE_cxx=OFF -DENABLE_f77=OFF \
-DENABLEf95=OFF -DENABLE_python=OFF -DENABLE_java=OFF -DENABLE_tcl=OFF \
-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON -DBUILD_SHARED_LIBS=OFF \
../plplot_cmake >& cmake.out

You will undoubtedly want to use your own name for the installation prefix
directory location and for plplot_cmake (a freshly checked out PLplot source
tree from SourceForge). The rest of your cmake options should be identical
with those above. Those options assure verbose make output (including all
the compiler commands), turn off all language interfaces to our core C
library, turn off all devices other than wxwidgets, and build plplot
internally with static libraries.

(2b) The build.  Stay in the separate build tree you prepared with the
above cmake command and invoke

make >& make.out

You will find it doesn't work because you are mixing C and C++ code
(including the static wxwidgets library code as well as the wxwidgets PLplot
device code) into all executables you build that refer to the C++ wxwidgets
device.  We only have one such executable (an executable called plrender).
One method of beating the linking issue is to find the exact gcc command
that did not work from the above make.out file, and replace gcc with g++ to
get plrender linked properly for this special case of a static wxwidgets
library. However, for your minimal needs you don't really need plrender so
just touch the appropriate plrender file and proceed with make again to
finish the build.

(2c) The install.  Stay in the same directory and invoke

make install >& make_install.out

Again, there is trouble with plrender, but you solve it the same way. 
"touch" is easier than invoking an exact g++ command.  However, be sure to
touch plrender in the correct directory given by make_install.out rather
than the different directory where you touched plrender in (2b) above.
Do "make install" after the touch to finish the install.

Here are the essential installation results you should get from the above
steps.

cd /home/software/plplot_cvs/installcmake
find -type f
....
./share/plplot5.6.1/plstnd5.fnt
./share/plplot5.6.1/plxtnd5.fnt
....
./share/plplot5.6.1/examples/Makefile
./share/plplot5.6.1/examples/c/plcdemos.h
./share/plplot5.6.1/examples/c/x01c.c
./share/plplot5.6.1/examples/c/Makefile
....
./lib/libcsirocsa.a
./lib/libcsironn.a
./lib/libplplotd.a
./lib/pkgconfig/plplotd.pc
....
./include/plplot/plplot.h
+ many more essential PLplot headers.

(2d) Build the x01c example for static PLplot and wxwidgets libraries, but
with everything else shared.

cd /tmp
cp -a /home/software/plplot_cvs/installcmake/share/plplot5.6.1/examples .
cd examples/c
make x01c >& make_x01c.out

Again it won't work because of C/C++ linking issues and this time really
do replace gcc with g++ to fix the problem.  Note, this result does
use the static PLPlot libraries (and you should check that ./x01c -dev
wxwidgets gives good results) but we need one more step to make
that x01c executable completely static.

(2e) Build a completely static x01c example.

The above command for (2d) is transformed to a completely static build
with the -static gcc option.  (Also, you don't need rpath
since that is not relevant for a completly static build).  Also, you have
to add some libraries. Static linking must mention all the non-system
libraries in the correct order and in general you cannot be as sloppy about
libraries as in the shared case.  The result is as follows:

software@chickadee> g++ x01c.c -o x01c_static -static \
`PKG_CONFIG_PATH=/home/software/plplot_cvs/installcmake/lib/pkgconfig pkg-config --cflags --libs plplotd` \
-lX11 -lfontconfig -lXcursor -lXrender \
-lXext -lXft -lXrandr -lfreetype -lfontconfig -lX11 -lXi -lexpat -lXrender \
-lpangoft2-1.0 2>&1 |grep undefined |sort |uniq|wc -l
0

Note, all the required libraries that are listed out with the pkg-config
command supplemented by the trailing -l options must have the *.a static
form of library installed.  It was at this stage I discovered I would have
to build my own static version of the wxwidgets library since Ubuntu (and
Debian) do no supply the static version.  It's possible you will have
similar trouble with the other required libraries as well.  The solution is
usually to install -devel versions of library packages.

I used the grep undefined trick to keep track of all the undefined symbols
you get with static linking if you don't take care to specify all libraries
The wx-config result for wxwidgets (which is what our CBS uses to configure
the above pkg-config command) is good enough for shared linking, but doesn't
cut the mustard for static linking which is why I had to specify all those
additional libraries with the above -l options.  You also have to be careful
of static library order which is why some of those -l options are repeated.
The 0 at the end showed there were (finally after several hours effort to
correlate every undefined symbol with a library using google searches and
sometimes guesses) no undefined symbols in the result.

(3) Results:

Here is the size of the result:

software@chickadee> ls -lh x01c_static
-rwxr-xr-x  1 software software 12M Sep 22 22:38 x01c_static*

(I was actually expecting bigger so I am pleasantly surprised by that.)

ldd confirms the resulting x01c_static is completely static with no
dependencies on libraries.

./x01c_static gives the same results as the shared version (x01c built in step
(2d)

You must distribute the Hershey fonts with your application (plstnd5.fnt and
plxtnd5.fnt from above).  The location of those fonts can be specified with
the PLPLOT_LIB environment variable and if that is not specified or that
location does not contain the Hershey fonts, then it falls back to the
hard-coded install location, $prefix/share/plplot5.6.1 on the build box, see
above. Thus, your users will probably have to set PLPLOT_LIB since the
hard-coded location is unlikely to be relevant on their machine.

The above fonts are only 65K so it is not going to be onerous for you to
distribute them in addition to the large executable that is obtained from a
static build.

Note, one downside of the Hershey fonts are the resulting characters are
crude (completely unhinted) for screen display.  Fortunatley, the wxwidgets
device can also use a high-quality font alternative.  I have confirmed that
alternative font system works well with ./x01c_static, but you should cross
that bridge when you come to it.  For now, please concentrate on getting the
static x01c example built and working with the default Hershey fonts
following the instructions above.

This has been an interesting project, but I am also glad to be done with it.
For a while there I thought I was in a time warp to the early 80's when
every developer had to contend with static linking library order problems
and trying to figure out which undefined symbol came from what library.  In
those days you looked everything up in a large room completely filled with
computer manuals.  Now it is significantly easier with google, but still
difficult.

Good luck in mimicking my completely static build result.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________