From: Alan W. I. <ir...@be...> - 2003-03-27 16:13:08
|
On Thu, 27 Mar 2003, Rafael Laboissiere wrote: > Hi again, > > Could you please test the today's tarball in netbsd? I put some > fprintf(stderr) calls in ltdl.c in order to help us hunting down the SIGSEGV > bug. I am putting this back on list because the result is interesting. The java tweak worked, and the showstopper error message is now much more informative. ./get-drv-info echo xwin.la | sed 's/.la//' > xwin.rc dlerror: Shared object "libX11.so.6" not found libltdl error: can't open the module *** Error code 1 (continuing) all' not remade because of errors. However LD_LIBRARY_PATH solves the problem! export LD_LIBRARY_PATH=/usr/X11R6/lib/ [irwin@sparky drivers]$ ./get-drv-info xwin xwin:X-Window (Xlib):1:xwin:5:xw So we have two errors here. (1) Something is wrong with the linking of either xwin.so or get-drv-info on netbsd that is corrected by LD_LIBRARY_PATH. When this segfault problem first surfaced I reviewed this thoroughly for xwin.so, and I swear it is right. But I haven't looked at the get-drv-info linking. It is possible that libtool has a netbsd bug here, and it does not support the hierarchical linking model like it is supposed to. Because of work pressures I won't be able to do any more until tonight. However, tonight I will review both linking efforts in detail again and do lots of netbsd linking experiments to try and sort this all out. Also, lots of running of examples with LD_LIBRARY_PATH set just to make sure everything else is working properly on netbsd. (2) Something is badly wrong with libltdl. It should not segfault on linking errors (dlopen which it wraps does not). You have obviously worked around the problems enough to get a decent report out of libltdl now, but I hope you document the problem thoroughly and send in a bug report to libltdl about it because the current unpatched behaviour of segfaulting on any library error (you verified this happened in Linux as well if you simulated a linking error) is completely unacceptable. 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 __________________________ |
From: Rafael L. <lab...@ps...> - 2003-03-27 16:46:17
|
* Alan W. Irwin <ir...@be...> [2003-03-27 08:11]: > So we have two errors here. > > (1) Something is wrong with the linking of either xwin.so or get-drv-info > [...] > (2) Something is badly wrong with libltdl. [...] I have a third hypothesis here, but before I state it, could you please tell me what the following gives in netbsd for you: grep "^X_LIBS =" drivers/Makefile ? -- Rafael |
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 __________________________ |
From: Rafael L. <lab...@ps...> - 2003-03-28 08:45:24
|
* Alan W. Irwin <ir...@be...> [2003-03-27 20:37]: > 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 Huh? I only changed c/Makefile.examples.in. I have never touched the other three. > 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 will fix c/Makefile.examples.in, replacing the pattern rule by an old fashioned suffix rule, which should work in all platforms. If this work, then I will change the other three Makefile.examples.in. > ************* > > 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. From the autoconf documentation, top_builddir is always guaranteed to be relative, while abs_top_builddir is the absolute path. I am pretty sure that this will be the case forever (the Autoconf maintainers will be killed if they introduced this backwards incompatibility...). Okay, you fixed something that was broken, but a potential maintainance burden was introduced. I am going to change "../../.." to "../$(top_srcdir)" to make things better. I am not going to use abs_top_buildir, because it is not automatically AC_SUBSTituted by Automake (but we could do it manually, if we wish). > 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? I do not quite understand your request. Which cvs are you talking about? How can we apply a patch on a file that is installed automatically and locally by libtoolize in bootstrap.sh? -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-03-28 18:19:23
|
On Fri, 28 Mar 2003, Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2003-03-27 20:37]: > > > 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 > > Huh? I only changed c/Makefile.examples.in. I have never touched the other > three. Sorry! I assumed since you had put pattern rules in c/Makefile.examples.in that you had done the rest as well. > > > 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 will fix c/Makefile.examples.in, replacing the pattern rule by an old > fashioned suffix rule, which should work in all platforms. If this work, > then I will change the other three Makefile.examples.in. Thanks. Unfortunately, cannot test it yet because you haven't made a tarball yet.... But please go ahead regardless. Your other suffix rules work fine for netbsd. See below for the problems I am having making a tarball of my own. > > 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. > > >From the autoconf documentation, top_builddir is always guaranteed to be > relative, > > Okay, you fixed something that was broken, but a potential maintainance > burden was introduced. I am going to change "../../.." to > "../$(top_srcdir)" to make things better. I woke up this morning with the same idea to carefully check whether top_builddir was documented as relative, but you beat me to it. Thanks for the fix. > > > 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? > > I do not quite understand your request. Which cvs are you talking about? How > can we apply a patch on a file that is installed automatically and locally > by libtoolize in bootstrap.sh? I thought you had done changes to your local libltdl to remove the segfault, but looking in more detail at the new get-drv-info.c, I see that you assume a library linking problem will generate a libltdl segfault, and you intercept that. That is okay for now, but I believe the logic depends on libltdl segfaulting, and I assume that will not always be the case. Could you also put in a call to lt_dlerror after every call to libltdl routines and print out non-NULL results from that? That would continue to work when the segfault problems are eventually removed from libltdl. Also, I thought from your previous analysis you would be in a position to remove those segfaults from libltdl yourself by patching it, but it appears not. Now, on to my recent problems. You haven't made a tarball today, so I decided to create my own. But it is missing some items, in particular if I start with a fresh checkout and do the following here is what I get: software@starling> cp -a plplot_clean plplot_working software@starling> cd plplot_working /home/software/plplot_cvs/HEAD/plplot_working software@starling> ./bootstrap.sh; ./configure --enable-java --enable-builddoc >& configure.out Using aclocal options: -I /home/software/autotools/install/share/libtool/libltdl Running aclocal (GNU automake) 1.7.2... done Running autoheader (GNU Autoconf) 2.57... done Running automake (GNU automake) 1.7.2...configure.ac: installing `./install-sh' configure.ac: installing `./mkinstalldirs' configure.ac: installing `./missing' configure.ac:449: installing `./config.guess' configure.ac:449: installing `./config.sub' configure.ac:449: required file `./ltmain.sh' not found Makefile.am:31: required directory ./libltdl does not exist bindings/c++/Makefile.am: installing `./depcomp' drivers/Makefile.am: installing `./compile' Makefile.am:31: required directory ./libltdl does not exist done Running libtoolize (GNU libtool) 1.4.3... done Running autoconf (GNU Autoconf) 2.57... done software@starling> less configure.out software@starling> make dist >& make_dist.out software@starling> tar ztvf plplot-5.2.0.cvs.tar.gz | grep ltmain software@starling> ls -l ltmain* -rw-r--r-- 1 software software 142449 Mar 28 07:14 ltmain.sh How come ltmain.sh is not in the tarball even though it is in the tree? I notice ltmain.sh is in the tarball you made yesterday, and also in tarballs I have previously made myself. I expect it has something to do with starting with a clean tree. Would you please do that to see if you can replicate this error? Anyhow, netbsd "make" stops immediately with make all-recursive Making all in libltdl make: don't know how to make ./../ltmain.sh. Stop make: stopped in /home/irwin/plplot_working/libltdl *** Error code 1 Stop. make: stopped in /home/irwin/plplot_working *** Error code 1 Stop. make: stopped in /home/irwin/plplot_working Presumably this netbsd error is because of this missing file. There may be other missing files as well, but if you solve this one presumably you will solve the rest. Anyhow, please make a new tarball that includes ltmain.sh, and please tell me how I can do that as well on my own from a fresh checkout. BTW, I have changed test_python.sh to make it configurable. You invoke python on netbsd by typing python2.2 (ugh!) Ordinarily, I resist adjusting plplot to make up for broken systems, but I thought this change was worthwhile because RedHat seems broken as well (You invoke the latest python on that distribution using the "python2" command.) 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 __________________________ |
From: Rafael L. <lab...@ps...> - 2003-03-28 21:58:05
|
* Alan W. Irwin <ir...@be...> [2003-03-28 10:17]: > On Fri, 28 Mar 2003, Rafael Laboissiere wrote: > > I will fix c/Makefile.examples.in, replacing the pattern rule by an old > > fashioned suffix rule, which should work in all platforms. If this work, > > then I will change the other three Makefile.examples.in. > > Thanks. Unfortunately, cannot test it yet because you haven't made a tarball > yet.... But please go ahead regardless. Your other suffix rules work > fine for netbsd. Done. > I thought you had done changes to your local libltdl to remove the segfault, > but looking in more detail at the new get-drv-info.c, I see that you assume > a library linking problem will generate a libltdl segfault, and you > intercept that. The only purpose of my changes were to help chasing down the netbsd bug. I will let the SIGSEGV catching code there, in any case, since it may be useful in the future. On the other hand, the only change that I did in ltdl.c was the inclusion of some fprint(stderr) in well chosen places. That successfully caught the libX11 linking problem in netbsd. > That is okay for now, but I believe the logic depends on libltdl > segfaulting, and I assume that will not always be the case. Could you also > put in a call to lt_dlerror after every call to libltdl routines and print > out non-NULL results from that? Done. > That would continue to work when the segfault problems are eventually > removed from libltdl. That libltdl segfaults is a bad thing for sure, but notice that the xlibs installation in your netbsd system is terribly broken. > Also, I thought from your previous analysis you would be in a position to > remove those segfaults from libltdl yourself by patching it, but it appears > not. That would be great, but it is not the case. > Now, on to my recent problems. You haven't made a tarball today, so I > decided to create my own. But it is missing some items, in particular > if I start with a fresh checkout and do the following here is what I get: > > software@starling> cp -a plplot_clean plplot_working > software@starling> cd plplot_working > /home/software/plplot_cvs/HEAD/plplot_working > software@starling> ./bootstrap.sh; ./configure --enable-java --enable-builddoc >& configure.out > Using aclocal options: -I /home/software/autotools/install/share/libtool/libltdl > Running aclocal (GNU automake) 1.7.2... done > Running autoheader (GNU Autoconf) 2.57... done > Running automake (GNU automake) 1.7.2...configure.ac: installing `./install-sh' > configure.ac: installing `./mkinstalldirs' > configure.ac: installing `./missing' > configure.ac:449: installing `./config.guess' > configure.ac:449: installing `./config.sub' > configure.ac:449: required file `./ltmain.sh' not found > Makefile.am:31: required directory ./libltdl does not exist > bindings/c++/Makefile.am: installing `./depcomp' > drivers/Makefile.am: installing `./compile' > Makefile.am:31: required directory ./libltdl does not exist > done > Running libtoolize (GNU libtool) 1.4.3... done > Running autoconf (GNU Autoconf) 2.57... done > software@starling> less configure.out > software@starling> make dist >& make_dist.out > software@starling> tar ztvf plplot-5.2.0.cvs.tar.gz | grep ltmain > software@starling> ls -l ltmain* > -rw-r--r-- 1 software software 142449 Mar 28 07:14 ltmain.sh > > How come ltmain.sh is not in the tarball even though it is in the tree? I > notice ltmain.sh is in the tarball you made yesterday, and also in tarballs > I have previously made myself. I expect it has something to do with starting > with a clean tree. Would you please do that to see if you can replicate > this error? Fixed in CVS (hopefully). -- Rafael |
From: Rafael L. <lab...@ps...> - 2003-03-28 10:03:18
|
* Alan W. Irwin <ir...@be...> [2003-03-27 20:37]: > 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; Yes, for sure it is. If /usr/X11R6/lib is not in /etc/ld.so.conf (or whichever file is used in netbsd), then the system is broken. > 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, Indeed: in Debian, this is done in the postinst script of package xlibs: $ fgrep ld.so /var/lib/dpkg/info/xlibs* /var/lib/dpkg/info/xlibs.postinst:if ! grep -qs ^/usr/X11R6/lib\$ /etc/ld.so.conf; then /var/lib/dpkg/info/xlibs.postinst: echo /usr/X11R6/lib >> /etc/ld.so.conf > and I assume the rest of the unices would do this as well. Hopefully! > 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. Yes, and we should document this somewhere. -- Rafael |
From: <jc...@fe...> - 2003-03-28 15:30:13
|
On Friday 28 March 2003 04:37, Alan W. Irwin wrote: | A netbsd update. ... | ************* | 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 This is not up to date. Currently I don't set automatic replot, instead I recommend setting it. | 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/oc |tave/p4.m' This is also odd, as "grid" returns the current grid state. Perhaps the snapshot were made in the middle of some of my changes? Aren't you using "make dist"? I'm using it to generate a tarball for testing under OSF/1. I can now do it because I'm now able to generate the docs from docbook, thanks to Rafael help. | 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. Actually my default octave is now 2.0.17, so I test everything with it. So, please keeping using 2.1.xx so we can keep plplot_octave compatible with both Octave versions. BTW, have to tried to "compile" in the bsd machine the hello.cc file I send the other day? I'm curious. Thanks, Joao |
From: Rafael L. <lab...@ps...> - 2003-03-28 15:41:53
|
* João Cardoso <jc...@fe...> [2003-03-28 15:27]: > | 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/oc > |tave/p4.m' > > This is also odd, as "grid" returns the current grid state. > > Perhaps the snapshot were made in the middle of some of my changes? That is really strange, since in the error message above we see "plplot5.2.0.cvs.20030321". Alan, are you using the latest release candidate tarball (cvs.20030327)? I guarantee that the latest one is in synch with CVS (at least for the Octave stuff). > Aren't you using "make dist"? I'm using it to generate a tarball for > testing under OSF/1. I can now do it because I'm now able to generate > the docs from docbook, thanks to Rafael help. Yes, Alan, we probably forgot to tell you, but Joao is now able to built in RedHat (or SuSE, I do not know) all the docs: info, pdf, ps, html, nroff, everything! -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-03-28 18:35:58
|
On Fri, 28 Mar 2003, Rafael Laboissiere wrote: > * Jo=E3o Cardoso <jc...@fe...> [2003-03-28 15:27]: > > > | 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/oc > > |tave/p4.m' > > > > This is also odd, as "grid" returns the current grid state. > > > > Perhaps the snapshot were made in the middle of some of my changes? > > That is really strange, since in the error message above we see > "plplot5.2.0.cvs.20030321". Alan, are you using the latest release > candidate tarball (cvs.20030327)? I guarantee that the latest one is in > synch with CVS (at least for the Octave stuff). It was mostly up-to-date. (I was faking the date so I didn't have to regenerate the versioned documentation files.) I decided to start fresh thi= s morning which generated the ltmain.sh missing from tarball problems. Once Rafael sorts that problem out (preferably) or provides a tarball for today with my recent CVS changes and his, I will try again. > > > Aren't you using "make dist"? I'm using it to generate a tarball for > > testing under OSF/1. I can now do it because I'm now able to generate > > the docs from docbook, thanks to Rafael help. > > Yes, Alan, we probably forgot to tell you, but Joao is now able to built = in > RedHat (or SuSE, I do not know) all the docs: info, pdf, ps, html, nroff, > everything! That's wonderful news. I like that 50 per cent increase in the developers who can build the documentation! Please document what you did in README.developers. I haven't been able to build the docs on RH myself, yet. It seems every weekend there has been another plplot distraction of higher priority, but maybe this weekend. 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 softwar= e package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <lab...@ps...> - 2003-03-28 20:05:01
|
* Alan W. Irwin <ir...@be...> [2003-03-28 10:34]: > That's wonderful news. I like that 50 per cent increase in the developers > who can build the documentation! Please document what you did in > README.developers. I had to fix many things related to the inclusion of entities in the XML files, because the RH's libexpat was behaving differently from that in Debian. Besides this, I remember that Joao had to increase the pool size of jadetex. It is a FAQ, but I sent the recipe to Joao. Joao, could you please add that to README.developers? -- Rafael |
From: <jc...@fe...> - 2003-03-28 20:32:12
|
On Friday 28 March 2003 20:02, Rafael Laboissiere wrote: | * Alan W. Irwin <ir...@be...> [2003-03-28 10:34]: | > That's wonderful news. I like that 50 per cent increase in the | > developers who can build the documentation! Please document what | > you did in README.developers. | | I had to fix many things related to the inclusion of entities in the | XML files, because the RH's libexpat was behaving differently from | that in Debian. Besides this, I remember that Joao had to increase | the pool size of jadetex. It is a FAQ, but I sent the recipe to | Joao. Joao, could you please add that to README.developers? I add the configure options for SuSE-8.1 in that file -- they work on a normal user colleague computer. But the pdf couldn't be build because of lack of latex resources (pool size, if I remember correctly). In my computer I had to increase several parameters, don't remember which, and as I proceed through trial and error, I can't give that receipt 8-( Joao |