plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Re: Tweaked ltdl.c -> new tarball

[Alan W. I. <ir...@be...>]

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
__________________________

Re: [Plplot-devel] Re: Tweaked ltdl.c -> new tarball

[Alan W. I. <ir...@be...>]

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
__________________________

Re: [Plplot-devel] Re: Tweaked ltdl.c -> new tarball

[Rafael L. <lab...@ps...>]

* 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

Re: [Plplot-devel] Re: Tweaked ltdl.c -> new tarball

[<jc...@fe...>]

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

Re: [Plplot-devel] Re: Tweaked ltdl.c -> new tarball

[Rafael L. <lab...@ps...>]

* 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

Re: [Plplot-devel] Re: Tweaked ltdl.c -> new tarball

[Rafael L. <lab...@ps...>]

* 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

Re: [Plplot-devel] Re: Tweaked ltdl.c -> new tarball

[Alan W. I. <ir...@be...>]

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
__________________________

Re: [Plplot-devel] Re: Tweaked ltdl.c -> new tarball

[Alan W. I. <ir...@be...>]

On Thu, 27 Mar 2003, Rafael Laboissiere wrote:

> * 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
>
> ?

grep "^X_LIBS =" drivers/Makefile
X_LIBS =  -L/usr/X11R6/lib

So that seems fine.

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
__________________________

Re: [Plplot-devel] Re: Tweaked ltdl.c -> new tarball

[Rafael L. <lab...@ps...>]

* 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

[Plplot-devel] Re: Tweaked ltdl.c -> new tarball

[Alan W. I. <ir...@be...>]

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
__________________________

Re: [Plplot-devel] netbsd portability effort status--- one showstopper and 3 other problems

[Rafael L. <lab...@ps...>]

* Alan W. Irwin <ir...@be...> [2003-03-26 16:54]:

> Here are the latest results with plplot-5.2.0.cvs.20030326.tar.gz and
> tcl/tk and freetype disabled.
> 
> * All the mkoctfile configuration changes to compensate for the broken
> version on netbsd seem to be working.  The warning message about this
> came through loud and clear during configuration, and plplot_octave.oct
> built without any obvious error messages.  Thanks, Rafael!

Great.

> * Just noticed that Java configuration needs a tweak.  Even though I used a
> default configuration (java not enabled), the java build went ahead in any
> case.  I think the reason for the problem is lib_LTLIBRARIES =
> libplplotjava@LIB_TAG@.la appears outside the conditional. Do you agree,
> Rafael?

Sure.  When I put things related to $(javagenfiles) outside the conditional,
I accidentally put libplplotjava@LIB_TAG@.la too.  This is a mistake and I
will fix it.

> * The only build problem was
> 
> ./get-drv-info xwin
> libltdl error: can't open the module
> 
> This is more informative than the segfault we had before, but I don't know
> how to interpret this message.
> 
> Rafael?

As I suspected, this is a problem with the linker in netbsd and its source
may be elsewhere, not in the ltdl.c code.  I have to think in a way to debug
this.  Unfortunately, I do not have an access to a netbsd system, so Alan
will have to try my guesses.

> Rafael, I noticed this before, but forgot to ask; what does that Error
> reading address 0xe0: Invalid argument mean?  Is the null argument for the
> filename argument for try_dlopen causing the segfault?

No idea.  I will check this.

-- 
Rafael

Re: [Plplot-devel] netbsd portability effort status--- one showstopper and 3 other problems

[Alan W. I. <ir...@be...>]

On Wed, 26 Mar 2003, Rafael Laboissiere wrote:

> * Alan W. Irwin <ir...@be...> [2003-03-26 06:29]:
> > I will report back later about what your latest changes do (which I assume
> > will give the same information without having to use gdb).
>
> No, the informations are complementary.  The signal handler in get-drv-info
> gives the description of the error, while the gdb backtrace gives the place
> where the problem happened.

Here are the latest results with plplot-5.2.0.cvs.20030326.tar.gz and
tcl/tk and freetype disabled.

* All the mkoctfile configuration changes to compensate for the broken
version on netbsd seem to be working.  The warning message about this
came through loud and clear during configuration, and plplot_octave.oct
built without any obvious error messages.  Thanks, Rafael!

* Just noticed that Java configuration needs a tweak.  Even though I used a
default configuration (java not enabled), the java build went ahead in any
case.  I think the reason for the problem is lib_LTLIBRARIES =
libplplotjava@LIB_TAG@.la appears outside the conditional. Do you agree,
Rafael?

* The only build problem was

./get-drv-info xwin
libltdl error: can't open the module

This is more informative than the segfault we had before, but I don't know
how to interpret this message.

Rafael?

irwin@sparky gdb get-drv-info
GNU gdb 5.0nb1
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc--netbsdelf"...
(gdb) run xwin
Starting program: /home/irwin/plplot_working/drivers/get-drv-info xwin

Program received signal SIGSEGV, Segmentation fault.
0x12758 in tryall_dlopen_module (handle=0xeffff5ec, prefix=0x0, dirname=0x0,
    dlname=0x28060 "xwin.so") at ltdl.c:1979
1979      if (dirname[dirname_len -1] == '/')
(gdb) bt
#0  0x12758 in tryall_dlopen_module (handle=0xeffff5ec, prefix=0x0,
    dirname=0x0, dlname=0x28060 "xwin.so") at ltdl.c:1979
#1  0x128e0 in find_module (handle=0xeffff5ec, dir=0x0,
    libdir=0x2e080 "/home/irwin/plplot_install/lib/plplot5.2.0.cvs.20030326/data/../driversd", dlname=0x28060 "xwin.so", old_name=0x0, installed=0)
    at ltdl.c:2045
#2  0x13840 in try_dlopen (phandle=0xeffff65c,
    filename=0xe0 <Error reading address 0xe0: Invalid argument>)
    at ltdl.c:2823
#3  0x13d70 in lt_dlopenext (filename=0xeffff9d8 "xwin") at ltdl.c:2983
#4  0x1105c in main (argc=2, argv=0xeffff8c4) at get-drv-info.c:48
#5  0x10da4 in ___start ()

Rafael, I noticed this before, but forgot to ask; what does that Error
reading address 0xe0: Invalid argument mean?  Is the null argument for the
filename argument for try_dlopen causing the segfault?

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
__________________________

Re: [Plplot-devel] netbsd portability effort status--- one showstopper and 3 other problems

[<jc...@fe...>]

On Wednesday 26 March 2003 15:33, Alan W. Irwin wrote:
| On Wed, 26 Mar 2003, [iso-8859-1] Jo=E3o Cardoso wrote:
| > On Wednesday 26 March 2003 03:05, Alan W. Irwin wrote:
| > | Have you been able to build octave on your OSF1 system?
| >
| > I have not tried, but the system mkoctfile says:
| > : ${SH_LD=3D"c++"}
| > : ${SH_LDFLAGS=3D"-shared -Xlinker -expect_unresolved -Xlinker '*'"}
|
| At least these flags are not near-empty like on netbsd so there is
| some hope you will be able to build octave on OSF1.

I really don't know how the netbsd packager was able to link octave with=20
those options, as "g++" links with "-lstdc++", which "ld" does not.

|  Anyhow, I
| suggest you do that experiment so that at least we can claim the
| octave interface to plplot works on at least one Unix system before
| the release.

The problem is that the system has gcc-3.0.3

Octave 2.0.xx needs gcc-2.8/9.xx while octave-2.1.4x needs gcc > 3.0.x
I tried to compile octave-2.0.17, 2.1.40 and 2.1.46. None succeeded.

I could try to compile gcc-3.2.2, but I probably would need to compile=20
other tools as well. As I use this machine just to test Plplot, I don't=20
think it is worth the effort.

If a system has octave, than it can have plplot_octave. This is for=20
sure.
This is not true in this particular machine because the gcc version that=20
was used to compile octave (gcc-2.8.0) was removed by the system adm=20
when he upgrade to gcc-3.0.3
 I could try to add a further test to configure, trying to compile a=20
hello.cc into a hello.oct, but I don't think it to be necessary.

I attach a small file that you can try to compile in the bsd machine=20
with "mkoctfile hello.cc" and then call from octave as "hello". It=20
works in my system with octave-mkoctfile-2.0.16/17-2.1.36/43.
If it works, then I will widthdraw my "This is for sure" comment above=20
:-)

Joao

Re: [Plplot-devel] Build result for Plplotter5.2.0 on Solaris

[Alan W. I. <ir...@be...>]

On Wed, 26 Mar 2003, Pankaj Laddha wrote:

> 2. If I define TCLLIBDIR and TKLIBDIR environment variables, configure script
> does not look for the correct version of tcl/tk library for linker. It just
> generates -ltcl, -ltk flags for linker. I used to work around to solve this. I
> created a softlink to appropriate libraries. eg. for -ltcl I created a softlink
> libtcl.so to libtcl8.4.so and so on or I have removed the above environment
> variable to force configure script to go through appropriate folders.
>

This is the exact same problem I am having with tcl/tk on netbsd.  There I
don't have root access so your symlink workaround is not available to me so
I have to disable it.  I think the only real solution to this problem is
fundamental change in how we configure tcl/tk, but I don't know how to make
the necessary changes myself.

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
__________________________

Re: [Plplot-devel] netbsd portability effort status--- one showstopper and 3 other problems

[Alan W. I. <ir...@be...>]

On Wed, 26 Mar 2003, [iso-8859-1] Jo=E3o Cardoso wrote:

> On Wednesday 26 March 2003 03:05, Alan W. Irwin wrote:
> | Have you been able to build octave on your OSF1 system?
>
> I have not tried, but the system mkoctfile says:
>
> : ${SH_LD=3D"c++"}
> : ${SH_LDFLAGS=3D"-shared -Xlinker -expect_unresolved -Xlinker '*'"}

At least these flags are not near-empty like on netbsd so there is some hop=
e
you will be able to build octave on OSF1.  Anyhow, I suggest you do that
experiment so that at least we can claim the octave interface to plplot
works on at least one Unix system before the release.

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
__________________________

[Plplot-devel] Build result for Plplotter5.2.0 on Solaris

[Pankaj L. <pa...@da...>]

Hi All,

I found following while building and testing the Plplotter 5.2.0 with tcl/tk
driver. Its bit long, sorry for that. I hope it would be useful to other
Plplotter user.

0. I am using Solaris 8, ActiveTcl8.4 versions of tools. I have downloaded the
plplot-5.2.0.tar.gz from the Plplotter site on 12 Feb 2003.

1. A bug which causes value of var variable as 5.1.0 in pkgindex.tcl file. I
believe this is fixed.

2. If I define TCLLIBDIR and TKLIBDIR environment variables, configure script
does not look for the correct version of tcl/tk library for linker. It just
generates -ltcl, -ltk flags for linker. I used to work around to solve this. I
created a softlink to appropriate libraries. eg. for -ltcl I created a softlink
libtcl.so to libtcl8.4.so and so on or I have removed the above environment
variable to force configure script to go through appropriate folders.

3. When I define USE_TCL_STUBS, USE_TK_STUBS compiler switches for tcl/tk
related files, I am getting compilation error in "tclMain.c" for following lines

EXTERN int Tcl_LinkVar();
int (*tclDummyLinkVarPtr)() = Tcl_LinkVar;

I have commented these lines and build was successful.

4. After building the libraries, I have used Plplplotter package for my testing.
When I try following on wish prompt
% package require Plplotter
5.2.0
% Plplotwin .p1
% pack .p1
% Plplotwin .p2

After the second call, My wish prompt used crash throwing some Xwindows error in
"XCreatePixmap()" function in "tkwin.c" file when Xsync() is called in the same
function. I found the problem was with following line.

dev->pixmap = Tk_GetPixmap(tkwd->display, Tk_WindowId(tkwin),
     Tk_Width(tkwin), Tk_Height(tkwin),
     DefaultDepthOfScreen(Tk_Screen(tkwin)));

When I comment these and use following  lines

dev->pixmap = Tk_GetPixmap(Tk_Display(tkwin), Tk_WindowId(tkwin),
     Tk_Width(tkwin), Tk_Height(tkwin),
     DefaultDepthOfScreen(Tk_Screen(tkwin)));

Plplotter works fine. Incidentally, the above lines are commented in the source
code with some explanation.

5. When I try to link standard tcl/tk static libraries like libtcl8.4.a etc, I
am getting redefinition linking error for following function in tclMain.c.
void TclSetStartupScriptFileName(char *fileName);
char *TclGetStartupScriptFileName(void);.
Again I am successful in building the package once, I comment the above
functions.

Currently I am able to use Plplotter package on Solaris 8 with ActiveTcl 8.4.

Please let me know if anyone has better solution for these problems.

Thanks
Pankaj.

Re: [Plplot-devel] netbsd portability effort status--- one showstopper and 3 other problems

[Alan W. I. <ir...@be...>]

On Wed, 26 Mar 2003, [iso-8859-1] Jo=E3o Cardoso wrote:

> Could you please run from within octave the command
>
> octave_config_info
>
> and tell us the result?

Although you told me later you didn't need this information, I thought the
question might come up again so I decided to give this information anyhow.
Please save for future reference.

octave
GNU Octave, version 2.1.34 (sparc--netbsdelf).
Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001 John W. Eaton.
This is free software with ABSOLUTELY NO WARRANTY.
For details, type warranty'.

*** This is a development version of Octave.  Development releases
*** are provided for people who want to help test, debug, and improve
*** Octave.
***
*** If you want a stable, well-tested version of Octave, you should be
*** using one of the stable releases (when this development release
*** was made, the latest stable version was 2.0.16).

octave:1> octave_config_info
ans =3D
{
  ALL_CFLAGS =3D -I. -I.. -I../liboctave -I../src -I../libcruft/misc  -I../=
glob -I
=2E./glob -I/usr/pkg/include -DHAVE_CONFIG_H  -O2
  ALL_CXXFLAGS =3D -I. -I.. -I../liboctave -I../src -I../libcruft/misc  -I.=
=2E/glob
-I../glob -I/usr/pkg/include -DHAVE_CONFIG_H -fno-implicit-templates -O2
  ARFLAGS =3D rc
  CFLAGS =3D -O2
  CPPFLAGS =3D
  CXXFLAGS =3D -O2
  CXX_VERSION =3D 2.95.3 20010315 (release) (NetBSD nb3)
  F2CFLAGS =3D
  FLIBS =3D
  LD_STATIC_FLAG =3D
  LEXLIB =3D
  LIBEXT =3D la
  LIBKPATHSEA =3D ../kpathsea/libkpathsea.a
  RANLIB =3D ranlib
  RDYNAMIC_FLAG =3D -rdynamic
  SHARED_LIBS =3D true
  SHLEXT =3D so
  YACC =3D ../missing bison
  bindir =3D /usr/pkg/bin
  imagepath =3D .:/usr/pkg/share/octave/2.1.34/imagelib//
  localoctfiledir =3D /usr/pkg/libexec/octave/site/oct/sparc--netbsdelf
  CPICFLAG =3D -fPIC
  CXXPICFLAG =3D -fPIC
  FC =3D cc
  FORTRAN_MAIN_FLAG =3D -u MAIN__
  LEX =3D flex
  LFLAGS =3D -t -I
  LIBOCTAVE =3D -loctave
  STATIC_LIBS =3D true
  datadir =3D /usr/pkg/share
  localfcnfiledir =3D /usr/pkg/share/octave/site/m
  octincludedir =3D /usr/pkg/include/octave-2.1.34
  EXE =3D
  GLOB_INCFLAGS =3D -I../glob -I../glob -I/usr/pkg/include
  LIBPLPLOT =3D
  LIBS =3D -lz -lm
  SH_LD =3D ld
  TERMLIBS =3D -lcurses
  UGLY_DEFS =3D -DOCTAVE_SOURCE=3D1 -DSEPCHAR=3D':' -DSEPCHAR_STR=3D":" -DU=
SE_READLINE=3D1
 -D__NO_MATH_INLINES=3D1 -DCXX_NEW_FRIEND_TEMPLATE_DECL=3D1 -DHAVE_LIBM=3D1=
 -DHAVE_LIB
Z=3D1 -DF77_APPEND_UNDERSCORE=3D1 -DHAVE_GETHOSTNAME=3D1 -DHAVE_GETPWNAM=3D=
1 -DSIZEOF_SH
ORT=3D2 -DSIZEOF_INT=3D4 -DSIZEOF_LONG=3D4 -DSIZEOF_LONG_LONG=3D8 -DHAVE_AL=
LOCA=3D1 -DNPOS
=3Dstd::string::npos -DSTDC_HEADERS=3D1 -DHAVE_DIRENT_H=3D1 -DTIME_WITH_SYS=
_TIME=3D1 -DH
AVE_SYS_WAIT_H=3D1 -DHAVE_ASSERT_H=3D1 -DHAVE_CURSES_H=3D1 -DHAVE_DLFCN_H=
=3D1 -DHAVE_FCN
TL_H=3D1 -DHAVE_FLOAT_H=3D1 -DHAVE_FNMATCH_H=3D1 -DHAVE_GLOB_H=3D1 -DHAVE_G=
RP_H=3D1 -DHAVE
_IEEEFP_H=3D1 -DHAVE_LIMITS_H=3D1 -DHAVE_MEMORY_H=3D1 -DHAVE_POLL_H=3D1 -DH=
AVE_PWD_H=3D1 -
DHAVE_SGTTY_H=3D1 -DHAVE_STDLIB_H=3D1 -DHAVE_STRING_H=3D1 -DHAVE_SYS_IOCTL_=
H=3D1 -DHAVE_
SYS_PARAM_H=3D1 -DHAVE_SYS_POLL_H=3D1 -DHAVE_SYS_RESOURCE_H=3D1 -DHAVE_SYS_=
SELECT_H=3D1
-DHAVE_SYS_STAT_H=3D1 -DHAVE_SYS_TIME_H=3D1 -DHAVE_SYS_TIMES_H=3D1 -DHAVE_S=
YS_TYPES_H=3D
1 -DHAVE_SYS_UTSNAME_H=3D1 -DHAVE_TERMCAP_H=3D1 -DHAVE_UNISTD_H=3D1 -DHAVE_=
VARARGS_H=3D1
 -DHAVE_ATEXIT=3D1 -DHAVE_BCOPY=3D1 -DHAVE_BZERO=3D1 -DHAVE_DUP2=3D1 -DHAVE=
_ENDGRENT=3D1 -
DHAVE_ENDPWENT=3D1 -DHAVE_EXECVP=3D1 -DHAVE_FCNTL=3D1 -DHAVE_FORK=3D1 -DHAV=
E_GETCWD=3D1 -D
HAVE_GETEGID=3D1 -DHAVE_GETEUID=3D1 -DHAVE_GETGID=3D1 -DHAVE_GETGRENT=3D1 -=
DHAVE_GETGRGI
D=3D1 -DHAVE_GETGRNAM=3D1 -DHAVE_GETPGRP=3D1 -DHAVE_GETPID=3D1 -DHAVE_GETPP=
ID=3D1 -DHAVE_G
ETPWENT=3D1 -DHAVE_GETPWUID=3D1 -DHAVE_GETTIMEOFDAY=3D1 -DHAVE_GETUID=3D1 -=
DHAVE_GETWD=3D1
 -DHAVE_LINK=3D1 -DHAVE_LOCALTIME_R=3D1 -DHAVE_LSTAT=3D1 -DHAVE_MEMMOVE=3D1=
 -DHAVE_MKDIR
=3D1 -DHAVE_MKFIFO=3D1 -DHAVE_PIPE=3D1 -DHAVE_POLL=3D1 -DHAVE_PUTENV=3D1 -D=
HAVE_READLINK=3D1
 -DHAVE_RENAME=3D1 -DHAVE_RINDEX=3D1 -DHAVE_RMDIR=3D1 -DHAVE_SELECT=3D1 -DH=
AVE_SETGRENT=3D
1 -DHAVE_SETPWENT=3D1 -DHAVE_SETVBUF=3D1 -DHAVE_SIGACTION=3D1 -DHAVE_SIGPEN=
DING=3D1 -DHA
VE_SIGPROCMASK=3D1 -DHAVE_SIGSUSPEND=3D1 -DHAVE_STAT=3D1 -DHAVE_STRCASECMP=
=3D1 -DHAVE_ST
RDUP=3D1 -DHAVE_STRERROR=3D1 -DHAVE_STRFTIME=3D1 -DHAVE_STRNCASECMP=3D1 -DH=
AVE_STRPTIME=3D
1 -DHAVE_SYMLINK=3D1 -DHAVE_TEMPNAM=3D1 -DHAVE_UMASK=3D1 -DHAVE_UNLINK=3D1 =
-DHAVE_USLEEP
=3D1 -DHAVE_VFPRINTF=3D1 -DHAVE_VSPRINTF=3D1 -DHAVE_VSNPRINTF=3D1 -DHAVE_WA=
ITPID=3D1 -DSMA
RT_PUTENV=3D1 -DHAVE_DLOPEN=3D1 -DHAVE_DLSYM=3D1 -DHAVE_DLERROR=3D1 -DHAVE_=
DLCLOSE=3D1 -DW
ITH_DL=3D1 -DWITH_DYNAMIC_LINKING=3D1 -DHAVE_TIMEVAL=3D1 -DHAVE_FINITE=3D1 =
-DHAVE_ISNAN=3D
1 -DHAVE_ISINF=3D1 -DHAVE_ACOSH=3D1 -DHAVE_ASINH=3D1 -DHAVE_ATANH=3D1 -DHAV=
E_ERF=3D1 -DHAV
E_ERFC=3D1 -DHAVE_ST_BLKSIZE=3D1 -DHAVE_ST_BLOCKS=3D1 -DHAVE_ST_RDEV=3D1 -D=
HAVE_TM_ZONE=3D
1 -DHAVE_GR_PASSWD=3D1 -DEXCEPTION_IN_MATH=3D1 -DRETSIGTYPE=3Dvoid -DSYS_SI=
GLIST_DECLA
RED=3D1 -DHAVE_SYS_SIGLIST=3D1 -DHAVE_POSIX_SIGNALS=3D1 -DHAVE_GETRUSAGE=3D=
1 -DHAVE_TIME
S=3D1 -DGNUPLOT_HAS_MULTIPLOT=3D1 -DGNUPLOT_HAS_FRAMES=3D1
  WITH_SHL =3D false
  exec_prefix =3D /usr/pkg
  imagedir =3D /usr/pkg/share/octave/2.1.34/imagelib
  startupfiledir =3D /usr/pkg/share/octave/2.1.34/m/startup
  ALL_FFLAGS =3D -O
  AR =3D ar
  BLAS_LIBS =3D
  CC_VERSION =3D 2.95.3 20010315 (release) (NetBSD nb3)
  CXX =3D c++
  DEFAULT_PAGER =3D less
  F2C =3D
  FFLAGS =3D -O
  LIBCRUFT =3D -lcruft
  LIBGLOB =3D ../glob/glob.o ../glob/fnmatch.o
  LIBREADLINE =3D /usr/pkg/lib/libreadline.so
  RLD_FLAG =3D
  WITH_DL =3D true
  WITH_DYNAMIC_LINKING =3D true
  config_opts =3D --with-g77 --enable-shared --enable-rpath -prefix=3D/usr/=
pkg --hos
t=3Dsparc--netbsdelf --prefix=3D/usr/pkg
  includedir =3D /usr/pkg/include
  infodir =3D /usr/pkg/info
  libexecdir =3D /usr/pkg/libexec
  mandir =3D /usr/pkg/man
  F77 =3D cc
  FPICFLAG =3D -fPIC
  LIBFLAGS =3D -L..
  LN_S =3D ln -s
  MKOCTFILE_INCFLAGS =3D -I/usr/pkg/include/octave-2.1.34 -I/usr/pkg/includ=
e/octav
e-2.1.34/octave -I/usr/pkg/include
  SHLEXT_VER =3D so.2.1.34
  archlibdir =3D /usr/pkg/libexec/octave/2.1.34/exec/sparc--netbsdelf
  dld =3D 1
  fcnfilepath =3D .:/usr/pkg/libexec/octave/2.1.34/site/oct/sparc--netbsdel=
f//:/us
r/pkg/libexec/octave/site/oct/sparc--netbsdelf//:/usr/pkg/share/octave/2.1.=
34/si
te/m//:/usr/pkg/share/octave/site/m//:/usr/pkg/libexec/octave/2.1.34/oct/sp=
arc--
netbsdelf//:/usr/pkg/share/octave/2.1.34/m//
  infofile =3D /usr/pkg/info/octave.info
  localverarchlibdir =3D /usr/pkg/libexec/octave/2.1.34/site/exec/sparc--ne=
tbsdelf
  man1dir =3D /usr/pkg/man/man1
  octlibdir =3D /usr/pkg/lib/octave-2.1.34
  ALL_LDFLAGS =3D -L.. -u MAIN__  -fPIC -L/usr/pkg/lib  -Wl,-R/usr/X11R6/li=
b -L/us
r/X11R6/lib -Wl,-R/usr/pkg/lib -L/usr/pkg/lib
  DLFCN_INCFLAGS =3D
  LDFLAGS =3D -L/usr/pkg/lib  -Wl,-R/usr/X11R6/lib -L/usr/X11R6/lib -Wl,-R/=
usr/pkg
/lib -L/usr/pkg/lib
  RUNTEST =3D
  localstartupfiledir =3D /usr/pkg/share/octave/site/m/startup
  localveroctfiledir =3D /usr/pkg/libexec/octave/2.1.34/site/oct/sparc--net=
bsdelf
  octfiledir =3D /usr/pkg/libexec/octave/2.1.34/oct/sparc--netbsdelf
  CC =3D cc
  CXXCPP =3D c++ -E
  LIBDLFCN =3D
  XTRA_CFLAGS =3D
  XTRA_CXXFLAGS =3D -fno-implicit-templates
  YFLAGS =3D -dv
  canonical_host_type =3D sparc--netbsdelf
  fcnfiledir =3D /usr/pkg/share/octave/2.1.34/m
  libdir =3D /usr/pkg/lib
  localoctfilepath =3D /usr/pkg/libexec/octave/2.1.34/site/oct/sparc--netbs=
delf//:
/usr/pkg/libexec/octave/site/oct/sparc--netbsdelf//
  localverfcnfiledir =3D /usr/pkg/share/octave/2.1.34/site/m
  man1ext =3D .1
  prefix =3D /usr/pkg
  version =3D 2.1.34
  INCFLAGS =3D -I. -I.. -I../liboctave -I../src -I../libcruft/misc  -I../gl=
ob -I..
/glob -I/usr/pkg/include
  LIBOCTINTERP =3D -loctinterp
  OCTAVE_LITE =3D false
  SH_LDFLAGS =3D
  SONAME_FLAGS =3D
  localarchlibdir =3D /usr/pkg/libexec/octave/site/exec/sparc--netbsdelf
  localfcnfilepath =3D /usr/pkg/share/octave/2.1.34/site/m//:/usr/pkg/share=
/octave
/site/m//
}

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
__________________________

Re: [Plplot-devel] netbsd portability effort status--- one showstopper and 3 other problems

[Rafael L. <lab...@ps...>]

* Alan W. Irwin <ir...@be...> [2003-03-26 06:29]:

> This was done with yesterday's system.  

Thanks.

> I will report back later about what your latest changes do (which I assume
> will give the same information without having to use gdb).

No, the informations are complementary.  The signal handler in get-drv-info
gives the description of the error, while the gdb backtrace gives the place
where the problem happened.

-- 
Rafael

Re: [Plplot-devel] netbsd portability effort status--- one showstopper and 3 other problems

[Rafael L. <lab...@ps...>]

* Alan W. Irwin <ir...@be...> [2003-03-26 06:54]:

> Yes, that works.  But I hate like hell to embed special stuff in our own
> configuration system just to compensate for this brokeness.  If you do
> something like that please put lots of warning commentary around it that it
> stays in our configuration only as long as netbsd is broken.

Okay.

-- 
Rafael

Re: [Plplot-devel] netbsd portability effort status--- one showstopper and 3 other problems

[Alan W. I. <ir...@be...>]

On Wed, 26 Mar 2003, Rafael Laboissiere wrote:

> * Alan W. Irwin <ir...@be...> [2003-03-25 19:05]:

> > grep SH_LD `which mkoctfile` |grep '='
> > : ${SH_LD="ld"}
> > : ${SH_LDFLAGS=""}
> >
> >
> > When it should have been the Linux result:
> >
> > grep SH_LD `which mkoctfile` | grep '='
> > : ${SH_LD="/usr/bin/g++"}
> > : ${SH_LDFLAGS="-shared"}
>
> We could find a workaround for this brokenness by checking for g++ in
> configure.ac and modifying bindings/octave/Makefile.am such that mkoctfile
> is invoked like this for netbsd:
>
>     SH_LD="/usr/bin/g++" SH_LDFLAGS="-shared" mkoctfile [...]
>
> Please, could you confirm that the above work in your netbsd system?

Yes, that works.  But I hate like hell to embed special stuff in our own
configuration system just to compensate for this brokeness.  If you do
something like that please put lots of warning commentary around it that it
stays in our configuration only as long as netbsd is broken.

>
> An aside question: what is the result of this in netbsd:
>
>     echo `uname -s`-`uname -r`

NetBSD-1.6M

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
__________________________

Re: [Plplot-devel] Re: [Plplot-cvs] CVS update notice (plplot/doc/docbook)

[Rafael L. <lab...@ps...>]

* João Cardoso <jc...@fe...> [2003-03-26 14:46]:

> On Tuesday 25 March 2003 11:28, Rafael Laboissiere wrote:
> ...
> 
> | Unrelated to the above, a check for the libm is introduced before the
> | check of functions isinf, finite, and isnan.  This should fix the
> | configure problem in Alpha-OSF.
> 
> And it did.

Great.

> So this is the recommended approach to add -lm to LIBS, which is latter 
> on used on all tests. This should be done early in configure,as -lm is 
> certainly required in most unix non-linux systems

Feel free to move it to the place you think it is appropriate.

-- 
Rafael

[Plplot-devel] Re: [Plplot-cvs] CVS update notice (plplot/doc/docbook)

[<jc...@fe...>]

On Tuesday 25 March 2003 11:28, Rafael Laboissiere wrote:
...

| Unrelated to the above, a check for the libm is introduced before the
| check of functions isinf, finite, and isnan.  This should fix the
| configure problem in Alpha-OSF.

And it did.

So this is the recommended approach to add -lm to LIBS, which is latter 
on used on all tests. This should be done early in configure,as -lm is 
certainly required in most unix non-linux systems

Thanks,
Joao

Re: [Plplot-devel] netbsd portability effort status--- one showstopper and 3 other problems

[Alan W. I. <ir...@be...>]

On Wed, 26 Mar 2003, Rafael Laboissiere wrote:

> * Alan W. Irwin <ir...@be...> [2003-03-25 17:02]:
>
> > This is still a showstopper with Rafael's patched debian version of
> > libtool.
> >
> > ./get-drv-info xwin
> > Segmentation fault (core dumped)
>
> What is the output of the following in netbsd:
>
>     gdb ./get-drv-info
>     run xwin
>     bt

This was done with yesterday's system.  I will report back later about
what your latest changes do (which I assume will give the same information
without having to use gdb).

gdb ./get-drv-info
GNU gdb 5.0nb1
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc--netbsdelf"...
(gdb) run xwin
Starting program: /home/irwin/plplot_working/drivers/./get-drv-info xwin

Program received signal SIGSEGV, Segmentation fault.
0x126c0 in tryall_dlopen_module (handle=0xeffff5ec, prefix=0x0, dirname=0x0,
    dlname=0x28060 "xwin.so") at ltdl.c:1979
1979      if (dirname[dirname_len -1] == '/')
(gdb) bt
#0  0x126c0 in tryall_dlopen_module (handle=0xeffff5ec, prefix=0x0,
    dirname=0x0, dlname=0x28060 "xwin.so") at ltdl.c:1979
#1  0x12848 in find_module (handle=0xeffff5ec, dir=0x0,
    libdir=0x2e080 "/home/irwin/plplot_install/lib/plplot5.2.0.cvs.20030325/data/../driversd", dlname=0x28060 "xwin.so", old_name=0x0, installed=0)
    at ltdl.c:2045
#2  0x137a8 in try_dlopen (phandle=0xeffff65c,
    filename=0xe0 <Error reading address 0xe0: Invalid argument>)
    at ltdl.c:2823
#3  0x13cd8 in lt_dlopenext (filename=0xeffff9da "xwin") at ltdl.c:2983
#4  0x10fc4 in main (argc=2, argv=0xeffff9da) at get-drv-info.c:35
#5  0x10d44 in ___start ()

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
__________________________

Re: [Plplot-devel] netbsd portability effort status--- one showstopper and 3 other problems

[<jc...@fe...>]

On Wednesday 26 March 2003 03:05, Alan W. Irwin wrote:
| On Wed, 26 Mar 2003, Joao Cardoso wrote:
...

| Inspired by your question and these results, I did a lot of
| experimentation and finally found that if
|
| ld -o plplot_octave.oct plplot_octave.o -L../../src/.libs -lplplotd
|
| is replaced by
|
| g++ -shared -o plplot_octave.oct plplot_octave.o -L../../src/.libs
| -lplplotd
|
| then all the linking problems disappear!  So clearly, the netbsd
| version of mkoctfile is set up improperly for that system:
|
| i.e.,
|
| grep SH_LD `which mkoctfile` |grep '='
|
| : ${SH_LD="ld"}
| : ${SH_LDFLAGS=""}
|
| When it should have been the Linux result:
|
| grep SH_LD `which mkoctfile` | grep '='
|
| : ${SH_LD="/usr/bin/g++"}
| : ${SH_LDFLAGS="-shared"}
|
| Have you been able to build octave on your OSF1 system?

I have not tried, but the system mkoctfile says:

: ${SH_LD="c++"}
: ${SH_LDFLAGS="-shared -Xlinker -expect_unresolved -Xlinker '*'"}

Forget my other mail where I ask you to run octave_config_info.
Only on octave versions 2.1xx is there information about SH_LD and 
SH_LDFLAGS.

|  I am trying
| to get some idea (2 data points are more statistically significant
| than 1 ...;-)) whether this is just a netbsd problem with mkoctfile
| or are we going to have consistent problems when we use mkoctfile on
| any Unix system other than Linux?

Perhaps you should contact the package maintainer, or send a bug-report 
to the Octave lists. The second is not very likely to show results, as 
2.1.xx is the main concern.

Joao

|
| 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
| __________________________

Re: [Plplot-devel] netbsd portability effort status--- one showstopper and 3 other problems

[<jc...@fe...>]

On Wednesday 26 March 2003 03:05, Alan W. Irwin wrote:
| On Wed, 26 Mar 2003, Joao Cardoso wrote:
...

| Inspired by your question and these results, I did a lot of
| experimentation and finally found that if
|
| ld -o plplot_octave.oct plplot_octave.o -L../../src/.libs -lplplotd
|
| is replaced by
|
| g++ -shared -o plplot_octave.oct plplot_octave.o -L../../src/.libs
| -lplplotd
|
| then all the linking problems disappear!  So clearly, the netbsd
| version of mkoctfile is set up improperly for that system:

Could you please run from within octave the command

octave_config_info

and tell us the result?

Thanks,
Joao