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 |