Menu
▾
▴
Re: [Plplot-devel] Re: Tweaked ltdl.c -> new tarball
|
From: Alan W. I. <ir...@be...> - 2003-03-28 04:38:59
|
A netbsd update.
Rafael, the gnu make pattern rules you put into
c++/Makefile.examples.in f77/Makefile.examples.in
c/Makefile.examples.in tk/Makefile.examples.in
should be changed to something that works on all Unix platforms. These
rules stopped me from running make in the examples subdirectories for
netbsd.
I did build x01c by hand using plplot_libtool, and it makes identical
postscript results to my Debian box. These identical results with the
dynamic ps driver are a good basic verification that libltdl and everything
else are working properly.
I also was able to run
./plplot-test.sh --front-end=python
and
./plplot-test.sh --front-end=octave
the results were different from the Linux side and generally slightly
different in length, but I haven't investigated that further yet since there
are always some expected differences for some of the examples between
platforms because of the precision issues (16-bit x and y coordinates) in
libplplot itself (until Geoffrey implements his ideas for an option for
higher-precision coordinates).
Anyhow, the python and octave results seemed to build fine without any
obvious errors so that reinforces the impression that netbsd is basically
fine.
*************
Side Linux issue for Joao. netbsd seemed fine for octave 2.1. However,
when I first attempted the comparison on the Linux side, octave 2.0
bombed with
./plplot-test.sh --front-end=octave
warning: Setting 'automatic_replot' to 1
Opened p1.ps
Opened p2.ps
Opened p3.ps
Opened p4.ps
error: value on right hand side of assignment is undefined
error: evaluating assignment expression near line 23, column 6
error: called from p4' in file
/usr/local/plplot_at/lib/plplot5.2.0.cvs.20030321/data/../examples/octave/p4.m'
I have since switched to octave 2.1.35 for Debian, and all is well in that
case, and I don't intend to switch back. However, Joao, if you still want
your efforts to work for 2.0, then there is some maintenance work you have
to do.
*************
Another Linux side issue. If matwrap is installed on the system (as in my
case) then the present configuration doesn't work. Previously, the
execution of $(MATWRAP)=matwrap was fine since it just used the PATH, but now
perl $(MATWRAP) cannot find that installed perl script.
I have solved this by using the full path for matwrap in all cases. See
recent commit.
*************
Another octave issue. Without another change I just committed, the octave
documentation cannot be built. The problem is that top_srcdir = ../.., so
it only works if you stay in bindings/perl. So the fragment
( cd plplot_octave_txt ; \
$(PERL) $(top_srcdir)/doc/docbook/bin/api2text.pl \
$(top_srcdir)/docbook/src/plplotdoc.xml.in \
$(top_srcdir)/doc/docbook/src/api.xml ) \
had to be replaced by
( cd plplot_octave_txt ; \
$(PERL) ../../../doc/docbook/bin/api2text.pl \
../../../doc/docbook/src/plplotdoc.xml.in \
../../../doc/docbook/src/api.xml ) \
I think it is better to be specific here rather than using something like
../$(top_srcdir) since we don't know whether top_srcdir will remain
relative forever.
N.B. I left the prerequisite list symbolic (i.e., with $(src_dir)) because
that is evaluated in bindings/perl rather than bindings/perl/octave_txt so
it is okay.
**************
Back to netbsd....
Here is some quick results with LD_LIBRARY_PATH experimentation on netbsd
with the installed versions of some of the devices.
[irwin@sparky driversd]$ LD_LIBRARY_PATH=/usr/X11R6/lib
[irwin@sparky driversd]$ ldd xwin.so
xwin.so:
-lm.0 => /usr/lib/libm.so.0
-lcsa.0 => /home/irwin/plplot_install/lib/libcsa.so.0
-lplplotd.8 => /home/irwin/plplot_install/lib/libplplotd.so.8
-lX11.6 => /usr/X11R6/lib/libX11.so.6
[irwin@sparky driversd]$ LD_LIBRARY_PATH=
[irwin@sparky driversd]$ ldd xwin.so
xwin.so:
-lm.0 => /usr/lib/libm.so.0
-lcsa.0 => /home/irwin/plplot_install/lib/libcsa.so.0
-lplplotd.8 => /home/irwin/plplot_install/lib/libplplotd.so.8
-lX11.6 => not found
./x01c -dev xwin
Plplot library version: 5.2.0.cvs.20030327
dlerror: Shared object "libX11.so.6" not found
dlerror: Shared object "libX11.so.6" not found
Unable to load driver: xwin.
*** PLPLOT ERROR ***
Unable to load driver
Program aborted
(./x01c gets much further with LD_LIBRARY_PATH set properly before it complains
I cannot display remotely. I will figure that display problem out later.)
So it looks like the X libraries are not officially installed as part
of the default library path on netbsd! However, their X applications
must be linked with rpath because we have
[irwin@sparky driversd]$ ldd /usr/X11R6/bin/xman
/usr/X11R6/bin/xman:
-lX11.6 => /usr/X11R6/lib/libX11.so.6
-lICE.6 => /usr/X11R6/lib/libICE.so.6
-lSM.6 => /usr/X11R6/lib/libSM.so.6
-lXt.6 => /usr/X11R6/lib/libXt.so.6
-lXext.6 => /usr/X11R6/lib/libXext.so.6
-lXmu.6 => /usr/X11R6/lib/libXmu.so.6
-lXaw.6 => /usr/X11R6/lib/libXaw.so.6
-lc.12 => /usr/lib/libc.so.12
In contrast to the situation for /usr/X11R6/lib, everything in
/usr/lib and /usr/pkg/lib seems to be on the default library path, e.g.,
[irwin@sparky driversd]$ ldd gd.so
gd.so:
-lm.0 => /usr/lib/libm.so.0
-lcsa.0 => /home/irwin/plplot_install/lib/libcsa.so.0
-lplplotd.8 => /home/irwin/plplot_install/lib/libplplotd.so.8
-lz.0 => /usr/lib/libz.so.0
-lpng.3 => /usr/pkg/lib/libpng.so.3
-ljpeg.62 => /usr/pkg/lib/libjpeg.so.62
-lintl.0 => /usr/lib/libintl.so.0
-lttf.4 => /usr/pkg/lib/libttf.so.4
-lgd.1 => /usr/pkg/lib/libgd.so.1
I don't quite know the best way to handle this X library path problem since
I don't know whether it is peculiar to netbsd or not. My own feeling is
netbsd is broken in this respect; certainly under Linux if you install a big
set of packages (such as the X set) you make darn sure the libraries are
accessible with ldconfig or whatever, and I assume the rest of the unices
would do this as well. Also, we do have one additional Unix data point from
Joao, where I assume (since his OSF1 install works) that the X library path
is in the default library path like it should be. Maurice, do you know the
situation with solaris?
For now, I am just willing to set LD_LOAD_LIBRARY_PATH by hand before the
netbsd build unless and until this problem shows up on another Unix system.
I think that basically resolves that issue.
Much more serious in my mind is the libltdl problem this whole effort has
revealed. If we had gotten a proper message back from dlopen (which libltdl
calls) I would have sorted this whole LD_LOAD_LIBRARY_PATH problem out quite
rapidly compared to the several days of part-time effort from Rafael and me.
Similarly, it is going to be bloody difficult to figure out what is wrong
with our users's linking if all we get is a segfault out of libltdl when
something isn't quite right with the linking of the shared object
being dlopened (as for xwin.so on the netbsd system).
Rafael, your new way of doing things works great for your tarball, but I
don't have access to that from cvs. Can you make your libltdl changes
available as a patch to cvs and also make sure your patch gets into the
upstream version so that we won't have to apply this patch forever?
So that really just leaves two issues to be resolved for netbsd. Once the
above pattern rule issues are fixed, I should be able to do some additional
wholesale comparisons between Linux and netbsd results for c, c++, and f77
examples. That comparison could be extended even further once the tcl/tk
configuration issues are sorted out.
Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the Canadian Centre for Climate Modelling and
Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software
package (plplot.org).
__________________________
Linux-powered Science
__________________________
|
