As of revision 12065, I got the -DBUILD_SHARED_LIBS=OFF
-DFORCE_EXTERNAL_STATIC=ON options to work, but only in an extremely
limited way.
Here are the relevant cmake output summary lines that show what the
limits currently are:
DRIVERS_LIST: mem;null;ps;svg;xfig
DEVICES_LIST: mem;null;ps;svg;xfig
(e.g., only devices with no external dependencies)
Language Bindings:
ENABLE_f77: ON ENABLE_f95: ON
ENABLE_cxx: ON ENABLE_java: OFF
ENABLE_python: OFF ENABLE_octave: OFF
ENABLE_tcl: OFF ENABLE_itcl: OFF
ENABLE_tk: OFF ENABLE_itk: OFF
ENABLE_pdl: OFF ENABLE_wxwidgets: OFF
ENABLE_ada: OFF ENABLE_d: ON
ENABLE_ocaml: OFF ENABLE_lua: OFF
ENABLE_qt: OFF ENABLE_pyqt4: OFF
That's pretty pitiful, but under these limits
-DFORCE_EXTERNAL_STATIC=ON does produce good test_noninteractive
results.
Furthermore, ldd shows the external library dependencies
are quite reduced under these circumstances.
software@raven> ldd examples/c/x01c
linux-vdso.so.1 => (0x00007fff759ff000)
libc.so.6 => /lib/libc.so.6 (0x00007fb0b5612000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb0b5997000)
(I presume these fundamental shared object libraries still appear
because they are assumed, i.e., CMake
doesn't actually look for or explicitly use these so the ".a" suffix
trick to select the static version doesn't work in this case.)
If I expand the above drivers list or the above list of language
bindings several different issues show up.
1. For Qt4, CMake internal checks fail. This gives a soft landing,
but the result is our qt devices are turned off. I cannot find any
relevant static flag for Qt4 support within CMake so this may be a bug
in static Qt4 support for Qt4 on CMake. Or more likely it is a bug in the
build of Qt4 itself since I can find no Debian package that contains,
for example, the static library, libQtCore.a.
2. The cairo device driver had issues with undefined pango/cairo
symbols.
pango/cairo are a subset of the GTK+ stack of libraries. This stack
exports its build information with pkg-config so our build system uses
the static variables (as returned by "pkg-config --static" to the
cmake environment) to decide what libraries to link. The only
conclusion I can draw here from the undefined symbols is that
"pkg-config --static" is not giving the correct static libraries in
the correct order to resolve all symbols. That is pretty
disappointing since normally the GTK+ stack of libraries is the
prototype for producing good results with pkg-config. But order
is extremely important for static library linking, and I guess
they just screwed that up.
3. We appear to screw up the order of X libraries linked for the
static case because the xwin device also fails to build with
undefined symbols for FORCE_EXTERNAL_STATIC.
4. The cairo device driver (and a number of additional device drivers
[e.g., -dev tk] and language
bindings [e.g., tcl] also had build issues with using dlopen. The error
message in all cases was similar to the following one received for the
cairo device driver:
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/libgmodule-2.0.a(gmodule.o):
In function g_module_open':
(.text+0x72d): warning: Using 'dlopen' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
Note, this is not a PLplot dlopen call since that is all turned
off for the FORCE_EXTERNAL_STATIC case. That option only can be
set for the case where PLplot's internal libraries are built statically
(i.e.,, -DBUILD_SHARED_LIBS=OFF) and devices are built statically
in that case as well (i.e., ENABLE_DYNDRIVERS is OFF which means
devices are part of libplplotd and run-time loaded with that
library as opposed to being dlopened.)
I think the only solution here is for external packages such as
pango/cairo not to use dlopen or else to specify that libgmodule-2.0
must be the shared version even though the --static option is
specified for pkg-config. In any case, this is their problem and not
ours.
5. For wxwidgets there is a wxWidgets_USE_STATIC CMake
variable which I use to obtain the static version of the libraries
for the FORCE_EXTERNAL_STATIC ON case. However, such libraries are
not available for Debian. When researching this I ran into
the following polemic against static libraries:
http://www.akkadia.org/drepper/no_static_linking.html
There are some good points there, but nevertheless one of his
principal points is not correct. As he says, it does appear virtually
impossible to avoid linking to _some_ shared libraries (as the above
ldd results show). However, systematic use of static libraries where
possible potentially does greatly reduce dependencies, and that is
quite useful in specialized environments where you might trust that
(say) the installed libc version is OK, but you don't want to put any
trust into the versions of other libraries that have been installed.
Unfortunately, it appears as the result of this polemic or similar
attitudes that static library support is very poor on Linux. For this
reason FORCE_EXTERNAL_STATIC ON is going to be mostly a
proof-of-concept/intellectual curiosity that is not going to get the
job done to remove inconsistencies between CMake linking and
pkg-config link flags derived for the --static case used in
traditional builds and tests with NON_TRANSITIVE ON. So I don't
plan to work further on FORCE_EXTERNAL_STATIC ON.
The pkg-config needs for the traditional build system for the
installed examples are quite limited (compared to our core build
systems use [via CMake] of pkg-config for discovering many of PLplot's
external library dependencies). Therefore, it is possible I could get
that former case to work another way (i.e., remove the inconsistency
with the core build by loading up my platform with the few additional
libraries that the --static option for pkg-config brings in for the
traditional build case). Anyhow, I will try that next before giving
up on getting NON_TRANSITIVE ON to work for the (corner?) case of
BUILD_SHARED_LIBS OFF combined with a traditional build and test of
the installed examples.
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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
