Menu
▾
▴
[Plplot-general] Configure/compile problems w/ 5.2.1 on Solaris 2.8
|
From: Diab J. <dj...@he...> - 2003-06-06 22:34:47
|
Hi,
First off, thanks for plplot. If the tone below is whiny, please
excuse it; I've just spent 20+ hours on getting everything going and
it's getting to me.
I'm compiling plplot version 5.2.1 on a Solaris system with Sun CC and
all of the third party libraries (png, zlib, etc) in a non-standard
directory. I support multiple platforms off of the same disk,
so use exec-prefix to split out the platform dependent bits.
I've run into a variety of problems. Some are due to Linux-specific
assumptions in the configure script, others because Solaris is weird,
and also because it is hard to get the configure script to look in
places other than the "standard ones" for the third party libraries.
The latter is painful as one has to carefully read the configure
script to understand how to override the search path for libraries.
In particular, the tcl/tk/itcl, etc. searches can be redirected
with environmental variables, but those are not defined, and require
a very painful deciphering of the configure script.
Here is a list of specific things I've dealt with.
=============================================================
Checks for png do not link against zlib, which, even though no symbols
are requested in the conftest.c program, causes the link to fail:
--------------------------------------------------------
configure:9851: checking for main in -lpng
Undefined first referenced
symbol in file
inflateEnd /proj/axaf/sun4u-SunOS-5/lib/libpng.so
deflateInit2_ /proj/axaf/sun4u-SunOS-5/lib/libpng.so
deflateReset /proj/axaf/sun4u-SunOS-5/lib/libpng.so
inflate /proj/axaf/sun4u-SunOS-5/lib/libpng.so
deflate /proj/axaf/sun4u-SunOS-5/lib/libpng.so
deflateEnd /proj/axaf/sun4u-SunOS-5/lib/libpng.so
inflateInit_ /proj/axaf/sun4u-SunOS-5/lib/libpng.so
inflateReset /proj/axaf/sun4u-SunOS-5/lib/libpng.so
crc32 /proj/axaf/sun4u-SunOS-5/lib/libpng.so
ld: fatal: Symbol referencing errors. No output written to conftest
--------------------------------------------------------
The libpng.so file has a dependency on libz in it:
--------------------------------------------------------
% dump -Lv /proj/axaf/lib/sun4u-SunOS-5/libpng.so.2
/proj/axaf/lib/sun4u-SunOS-5/libpng.so.2:
**** DYNAMIC SECTION INFORMATION ****
.dynamic:
[INDEX] Tag Value
[1] NEEDED libz.so
[3] RPATH /proj/axaf/lib/sun4u-SunOS-5
--------------------------------------------------------
but that doesn't seem to get through to the linker.
This seems to be a Solaris bizarrity.
The solution is to add zlib explicitly. However, the configure sequence
doesn't check for zlib until after it checks for png and jpeg. I think
that the logic needs to be changed so that zlib is checked for first,
then if png fails to be found, reset enable_zlib.
=============================================================
The next problem arises because the third party libraries
are not in the "standard" directories. I've preset LDFLAGS to add in
the appropriate directories, and that works well for finding them.
However, when gd is checked for png or jpeg functionality,
LDFLAGS is explicitly emptied (sysloc.in, line 243), which causes
the link step to fail. I note in passing that for some reason
LIBS is overriden as well, leading to this bizarre compile line
cc -o conftest -Idefault -I/proj/axaf/include conftest.c -Ldefault
-L/usr/local/lib -Ldefault -Ldefault -lgd -lpng -ljpeg -lz
(note all of the defaults). Why do LDFLAGS and LIBS need to be
overridden?
=============================================================
I've tried to patch sysloc.in to try and fix things, but can't for the
life of me get a new configure generated. running bootstrap.sh gives
me the following:
pelf% bootstrap.sh -I /proj/axaf/share/libtool/libltdl
Using aclocal options: -I /proj/axaf/share/libtool/libltdl
Running aclocal (GNU automake) 1.7.5... done
Running autoheader (GNU autoconf) 2.49a...autoconf: configure.in: No such file or directory
done
Running libtoolize (GNU libtool) 1.4.2... done
Running automake (GNU automake) 1.7.5...configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found.
configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE,
configure.ac: that aclocal.m4 is present in the top-level directory,
configure.ac: and that aclocal.m4 was recently regenerated (using aclocal).
automake: no `Makefile.am' found or specified
done
Running autoconf (GNU autoconf) 2.49a...autoconf: configure.in: No such file or directory
done
Regenerating libltdl/configure... done
=============================================================
When linking the c++, tcl and f77 binding libraries as well as the
drivers, -no-undefined is passed to libtool in the link stage.
Because the linker isn't being pointed at the underlying Solaris
libraries (buried deep in SUNWspro land) the links are failing. Note
that actual compilation of applications against the libraries (e.g.
the example programs) works fine, as the compiler is used to link, and
it knows where to find things. So, I removed -no-undefined.
=============================================================
The configure script searches for lib{tcl,tk}$version.$suffix,
but later links against -ltcl and -ltk. The standard installation
(i.e. from source) of tcl and tk doesn't create separate libtcl.so
and libtk.so links to the version libraries. This causes the
link to fail; the configure script should fail instead. I wonder
if it shouldn't actually link against a versioned library?
=============================================================
drivers/ntk.c contains un-escaped embedded newlines in character constants.
According to my trusty C reference manual (Harbison&Steele), embedded
newlines must be escaped. Sun's c doesn't like it either. If the
newlines aren't needed, then each "chunk" of the string can be
enclosed in double quotes, and the preprocessor will concatenate them
automatically.
=============================================================
configure uses $prefix instead of $exec_prefix when constructing
BIN_DIR and LIB_DIR. This causes much fun
=============================================================
FWIW, I've got a patch file which conglomerates all of the changes
I made. Unfortunately some of the changes are patches against
the configure script, not the inputs to the script, because of the
aforementioned problems recreating it. Lemme know if it's of any
interest.
After all of that, most everything works, except for the xwin driver,
which I'll be whining about in another email...
Thanks,
Diab
|
