plplot-devel — Technical discussion about PLplot development

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

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

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

> 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"}

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?

An aside question: what is the result of this in netbsd:

    echo `uname -s`-`uname -r`

?

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

-- 
Rafael

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

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

On Wed, 26 Mar 2003, Joao Cardoso wrote:

> > Joao, do you have
> > any OSF1 results for using the
> >
> > ./get-drv-info xwin
> >
> > command in the drivers directory?
>
> Yes, it is OK:
>
> bash-2.01$ ./get-drv-info gd
> Could not open driver module gd
> bash-2.01$ ./get-drv-info ps
> ps:PostScript File (monochrome):0:ps:29:psm
> psc:PostScript File (color):0:ps:30:pscbash-2.01$
> bash-2.01$ ./get-drv-info xwin
> xwin:X-Window (Xlib):1:xwin:5:xwbash-2.01$

Thanks for that additional information.

> > command which generates the following messages:
> >
> > ld: warning: cannot find entry symbol _start; defaulting to 00014d98
> > plplot_octave.o: In function `str_vec_compare(void const *, void const *)':
> > plplot_octave.o(.text+0x1aa4): undefined reference to `basic_string<char,
> > string_char_traits<char>, __default_alloc_template<false, 0>
> > >::compare(basic_string<char, string_char_traits<char>,
> > __default_alloc_template<false, 0> > const &, unsigned long, unsigned long)
> > const' plplot_octave.o: In function `_arraylen(octave_value const &)':
> > plplot_octave.o(.text+0x1b00): undefined reference to `umul'
> > plplot_octave.o: In function `_wrap_pl_setcontlabelformat(octave_value_list
> > const &, int)': plplot_octave.o(.text+0x1e30): undefined reference to
> > `octave_value::octave_value(void)'
>
> This looks like a libstdc question? Or a static Octave? Is Octave compiled
> with shared libs? What do
>
> ldd `which octave`
>
> reports? Does liboctinterp/liboctave/libcruft appears?
>
> ...
> liboctinterp.so.2.1.36 => /usr/local/lib/octave-2.1.36/liboctinterp.so.2.1.36
>  liboctave.so.2.1.36 => /usr/local/lib/octave-2.1.36/liboctave.so.2.1.36
> libcruft.so.2.1.36 => /usr/local/lib/octave-2.1.36/libcruft.so.2.1.36


ldd `which octave`
/usr/pkg/bin/octave:
         -loctinterp.2 => /usr/pkg/lib/liboctinterp.so.2
         -loctave.2 => /usr/pkg/lib/liboctave.so.2
         -lcruft.2 => /usr/pkg/lib/libcruft.so.2
         -lreadline.4 => /usr/pkg/lib/libreadline.so.4
         -lcurses.5 => /usr/lib/libcurses.so.5
         -lz.0 => /usr/lib/libz.so.0
         -lg2c.1 => /usr/lib/libg2c.so.1
         -lstdc++.4 => /usr/lib/libstdc++.so.4
         -lm.0 => /usr/lib/libm.so.0
         -lc.12 => /usr/lib/libc.so.12

Thanks for that suggestion (which I should have thought of myself).  It
appears that octave is dynamically linked to all these libraries (including
libcruft) and they are all present on the netbsd system.

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

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

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

On Wednesday 26 March 2003 01:02, Alan W. Irwin wrote:
> Here is an update on the netbsd status.
>
> On Mon, 24 Mar 2003, Alan W. Irwin wrote:
> > Here is the current status of plplot on netbsd.
> >
> > There is one issue that is a real showstopper for netbsd (and perhaps
> > other unices).  The ./get-drv-info helper application segfaults when it
> > tries to obtain information about the xwin driver.
>
> This is still a showstopper with Rafael's patched debian version of
> libtool.
>
> ./get-drv-info xwin
> Segmentation fault (core dumped)
>
> ./get-drv-info gd
> jpeg:JPEG file:0:gd:40:jpeg
> png:PNG file:0:gd:39:png
>
> Rafael, can you recommend some later version of libtool for me
> to try?  Are they close to their next release now?
>
> Joao, do you have
> any OSF1 results for using the
>
> ./get-drv-info xwin
>
> command in the drivers directory?

Yes, it is OK:

bash-2.01$ ./get-drv-info gd
Could not open driver module gd
bash-2.01$ ./get-drv-info ps
ps:PostScript File (monochrome):0:ps:29:psm
psc:PostScript File (color):0:ps:30:pscbash-2.01$ 
bash-2.01$ ./get-drv-info xwin
xwin:X-Window (Xlib):1:xwin:5:xwbash-2.01$ 

I still had not time to test the isnan configure issue.

Joao

>
> > Here are some additional issues that need to be addressed but which I can
> > bypass for now using --disable-tcl --without-freetype --disable-octave
>
> The tcl issue is still not addressed.
>
> I had some correspondence with Andrew about the freetype issue. 
> Apparently, ft2build.h is considered an essential front end to more
> volatile changes in other freetype2 headers so it should not be bypassed. 
> Since netbsd did not include ft2build.h, our conclusion is freetype2
> packaging is broken for netbsd.  For all further netbsd tests I will turn
> off freetype using --without-freetype.
>
> Rafael's perl changes allowed me to try octave on netbsd, but I conclude
> mkoctfile or the octave installation is broken there.  The compile step is
> done with the same warning messages as on the Linux side of things, but the
> link step is done with a bare
>
> ld -o plplot_octave.oct plplot_octave.o -L../../src/.libs -lplplotd
>
> command which generates the following messages:
>
> ld: warning: cannot find entry symbol _start; defaulting to 00014d98
> plplot_octave.o: In function `str_vec_compare(void const *, void const *)':
> plplot_octave.o(.text+0x1aa4): undefined reference to `basic_string<char,
> string_char_traits<char>, __default_alloc_template<false, 0>
> >::compare(basic_string<char, string_char_traits<char>,
> __default_alloc_template<false, 0> > const &, unsigned long, unsigned long)
> const' plplot_octave.o: In function `_arraylen(octave_value const &)':
> plplot_octave.o(.text+0x1b00): undefined reference to `umul'
> plplot_octave.o: In function `_wrap_pl_setcontlabelformat(octave_value_list
> const &, int)': plplot_octave.o(.text+0x1e30): undefined reference to
> `octave_value::octave_value(void)'

This looks like a libstdc question? Or a static Octave? Is Octave compiled 
with shared libs? What do

ldd `which octave`

reports? Does liboctinterp/liboctave/libcruft appears?

...
liboctinterp.so.2.1.36 => /usr/local/lib/octave-2.1.36/liboctinterp.so.2.1.36 
 liboctave.so.2.1.36 => /usr/local/lib/octave-2.1.36/liboctave.so.2.1.36 
libcruft.so.2.1.36 => /usr/local/lib/octave-2.1.36/libcruft.so.2.1.36 
...

>
> plus hundreds more of these undefined references.
>
> The equivalent command on the Linux side is fairly similar:
>
> /usr/bin/g++ -shared -o plplot_octave.oct plplot_octave.o -L../../src/.libs
> -lplplotd
>
> but of course with no warnings or messages.
>
> mkoctfile is supposed to have some sort of cross-platform support, but as
> far as I can tell when comparing the Linux and netbsd versions there is
> little difference between them except the link command differences above.
>
> It may be that in order to overcome this problem, we would have to go to a
> more powerful cross-platform solution such as libtool.  Rafael and Joao
> have not been keen on replacing mkoctfile with libtool to build the octave
> interface to plplot, but if they change their minds (after the current
> release; it is too late in this release cycle to try it), netbsd is a good
> test platform for a libtool solution. For example, I am glad I moved from
> the python native solution we had before (setup.py) to libtool to build the
> python interface to plplot.  That seems to work fine for netbsd (and every
> other platform where we have tried it) while the native method had lots of
> ifs, ands, and buts from one platform to the next.
>
> For now, I will avoid octave on netbsd by --disable-octave.
>
> So the scorecard is two issues (freetype and octave) which we have resolved
> by disabling since something is broken on netbsd, tcl/tk (still
> to be resolved), and the segfault which continues to be a major worry.
>
> 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
> __________________________
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

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

Here is an update on the netbsd status.

On Mon, 24 Mar 2003, Alan W. Irwin wrote:

> Here is the current status of plplot on netbsd.
>
> There is one issue that is a real showstopper for netbsd (and perhaps other
> unices).  The ./get-drv-info helper application segfaults when it tries to
> obtain information about the xwin driver.

This is still a showstopper with Rafael's patched debian version of
libtool.

./get-drv-info xwin
Segmentation fault (core dumped)

./get-drv-info gd
jpeg:JPEG file:0:gd:40:jpeg
png:PNG file:0:gd:39:png

Rafael, can you recommend some later version of libtool for me
to try?  Are they close to their next release now?

Joao, do you have
any OSF1 results for using the

./get-drv-info xwin

command in the drivers directory?

>
> Here are some additional issues that need to be addressed but which I can
> bypass for now using --disable-tcl --without-freetype --disable-octave

The tcl issue is still not addressed.

I had some correspondence with Andrew about the freetype issue.  Apparently,
ft2build.h is considered an essential front end to more volatile changes
in other freetype2 headers so it should not be bypassed.  Since netbsd did
not include ft2build.h, our conclusion is freetype2 packaging is broken
for netbsd.  For all further netbsd tests I will turn off freetype using
--without-freetype.

Rafael's perl changes allowed me to try octave on netbsd, but I conclude
mkoctfile or the octave installation is broken there.  The compile step is
done with the same warning messages as on the Linux side of things, but the
link step is done with a bare

ld -o plplot_octave.oct plplot_octave.o -L../../src/.libs -lplplotd

command which generates the following messages:

ld: warning: cannot find entry symbol _start; defaulting to 00014d98
plplot_octave.o: In function `str_vec_compare(void const *, void const *)':
plplot_octave.o(.text+0x1aa4): undefined reference to `basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> >::compare(basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> > const &, unsigned long, unsigned long) const'
plplot_octave.o: In function `_arraylen(octave_value const &)':
plplot_octave.o(.text+0x1b00): undefined reference to `umul'
plplot_octave.o: In function `_wrap_pl_setcontlabelformat(octave_value_list const &, int)':
plplot_octave.o(.text+0x1e30): undefined reference to `octave_value::octave_value(void)'

plus hundreds more of these undefined references.

The equivalent command on the Linux side is fairly similar:

/usr/bin/g++ -shared -o plplot_octave.oct plplot_octave.o -L../../src/.libs -lplplotd

but of course with no warnings or messages.

mkoctfile is supposed to have some sort of cross-platform support, but as
far as I can tell when comparing the Linux and netbsd versions there is
little difference between them except the link command differences above.

It may be that in order to overcome this problem, we would have to go to a
more powerful cross-platform solution such as libtool.  Rafael and Joao have
not been keen on replacing mkoctfile with libtool to build the octave
interface to plplot, but if they change their minds (after the current
release; it is too late in this release cycle to try it), netbsd is a good
test platform for a libtool solution. For example, I am glad I moved from
the python native solution we had before (setup.py) to libtool to build the
python interface to plplot.  That seems to work fine for netbsd (and every
other platform where we have tried it) while the native method had lots of
ifs, ands, and buts from one platform to the next.

For now, I will avoid octave on netbsd by --disable-octave.

So the scorecard is two issues (freetype and octave) which we have resolved
by disabling since something is broken on netbsd, tcl/tk (still
to be resolved), and the segfault which continues to be a major worry.

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] current supported toolset?

[Maurice L. <mj...@ga...>]

Rafael Laboissiere writes:
 > * Alan W. Irwin <ir...@be...> [2003-03-25 06:33]:
 > 
 > > Following up on Maurice's later comment: Rafael, would it be straightforward
 > > to supply a default for this -I option consisting of appending
 > > '../share/libtool/libltdl/' to the results of `which libtool`?  I believe
 > > such a default would take care of most if not all of our needs so we would
 > > could simply invoke ./bootstrap.sh without parameters most of the time.
 > 
 > Please, tell me what this shell snippet gives for you:
 > 
 >     prefix=`which libtool | sed 's:/bin/libtool::'`
 >     if test -n "$prefix" ; then
 >       acdir=${prefix}/share/libtool/libltdl
 >       if test -d $acdir ; then
 >         if test -f ${acdir}/aclocal.m4 ; then
 >           aclocal_opts="-I $acdir"
 >         fi
 >       fi
 >     fi
 >    echo aclocal_opts: $aclocal_opts    
 > 
 > If this works, I will integrate it into bootstrap.sh.

Works for me:

aclocal_opts: -I /home/mjl/local/SunOS/share/libtool/libltdl

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Re: [Plplot-devel] Are we at the release candidate stage now?

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

On Tue, 25 Mar 2003, Rafael Laboissiere wrote:

> I think that advertising the tarballs now as release candidates will have
> the psychological advantage of making users conscious of the proximity of
> the release.  Hence, they will be more willing to download the beast and
> test it. "CVS snapshot" is not as sexy and exciting as "Release Candidate".
>
> I cannot (of course) prove my claim and, since you are the Release Engineer,
> the final word is yours.  I am just afraid that only one week for users
> tests will be too short.

Actually, I agree with your claim that calling it a release candidate will
encourage people to try it more at this early date.  But my opinion is
"release candidate" is a special phrase that implies thorough testing by us,
and I don't want the user's to get that wrong impression and then angrily
flood us with a bunch of similar bug reports about something we should have
caught with our own testing.  I went through that poorly tested scenario
with PLplot-5.2.0, and I don't wish to repeat it if "release candidate"
unfairly raises the expectations of our users.

But that is the essential question here.  Does "release candidate" no longer
have any special meaning to our users since the phrase has been mis-used so
often for other projects?  What do the rest of you think? If there is strong
support amongst the developers here to call what we currently have
(segfaults and all) a release candidate, I would be willing to go along.  Or
maybe there is some compromise wording such as "pre-release candidate" we
would all be happy with?

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] current supported toolset?

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

On Tue, 25 Mar 2003, Rafael Laboissiere wrote:

> Please, tell me what this shell snippet gives for you:
>
> [....]If this works, I will integrate it into bootstrap.sh.

Thanks, Rafael, for making this improved aclocal_opts detection possible. It
works for me, and I like the fact that the user's choice is overridden for
aclocal_opts only in the case when the correct aclocal_opts is positively
detected for their libtool.  Therefore, I committed it subject, of course,
to any more tweaking you want to do.

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] Are we at the release candidate stage now?

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

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

> We have actually already advertised the CVS snapshots (not "release
> candidate", please, see below) on plplot-general. I encourage you to make
> another announcement there strongly asking for testing help. We have had
> nearly 4000 downloads of the 5.2.0 tarball as a result of my last release
> announcement on that list so that is a pretty good announcement venue. Also,
> I assume you are getting widespread Debian testing exposure through your
> package releases there.
> 
> BTW, I like the cautious phrasing you use in announcing the Debian packages.
> IMHO that caution is still appropriate because we are far from a release
> candidate at the moment. I would prefer our team of Unix cross-platform
> testers (Joao, Maurice, and me and anybody else lurking on this list) to
> finish our tests on the various platforms accessible to us before we start
> advertising a release candidate.

I think that advertising the tarballs now as release candidates will have
the psychological advantage of making users conscious of the proximity of
the release.  Hence, they will be more willing to download the beast and
test it. "CVS snapshot" is not as sexy and exciting as "Release Candidate". 

I cannot (of course) prove my claim and, since you are the Release Engineer,
the final word is yours.  I am just afraid that only one week for users
tests will be too short.

-- 
Rafael

[Plplot-devel] Are we at the release candidate stage now?

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

On Tue, 25 Mar 2003, Rafael Laboissiere wrote:

> It is probably a better idea to announce widely and immediately the
> availability of the release candidate tarballs, even if not all the
> portability problems are fixed.  The sooner the users start trying it, the
> sooner they will found bugs that we have overseen and the higher are the
> chances that we keep our schedule in time. Why wait until April 12th?
>

We have actually already advertised the CVS snapshots (not "release
candidate", please, see below) on plplot-general. I encourage you to make
another announcement there strongly asking for testing help. We have had
nearly 4000 downloads of the 5.2.0 tarball as a result of my last release
announcement on that list so that is a pretty good announcement venue. Also,
I assume you are getting widespread Debian testing exposure through your
package releases there.

BTW, I like the cautious phrasing you use in announcing the Debian packages.
IMHO that caution is still appropriate because we are far from a release
candidate at the moment. I would prefer our team of Unix cross-platform
testers (Joao, Maurice, and me and anybody else lurking on this list) to
finish our tests on the various platforms accessible to us before we start
advertising a release candidate.

What's the consensus here on that issue and much more importantly do the
cross-platform testers think you can finish your testing by 12 April?

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] current supported toolset?

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

* Rafael Laboissiere <lab...@ps...> [2003-03-25 15:02]:

> * Maurice LeBrun <mj...@ga...> [2003-03-25 06:23]:
> 
> > Maurice LeBrun writes:
> >  > Can anyone tell me what versions of autoconf/automake/libtool etc are
> >  > working for you?  Today I tried a new checkout of plplot on Solaris
> >  > and got a very long list of errors when running bootstrap.sh. E.g.
> >  > 
> >  > tonga$ ./bootstrap.sh 
> >  > Running aclocal (GNU automake) 1.7...aclocal: couldn't open directory
> >  > `/usr/share/libtool/libltdl': No such file or directory
> >  >  done
> >  > ...
> >  > Aside: the first error about looking under /usr/share/libtool/libltdl is
> >  > really strange.. I run everything local to my account --
> > 
> > Ahem.
> > 
> > tonga$ fgrep /usr/share *
> > bootstrap.sh:  -I /usr/share/libtool/libltdl
> > bootstrap.sh:aclocal_opts=${aclocal_opts:="-I /usr/share/libtool/libltdl"}
> > 
> > Not cool.  Surely there is a better way?
> 
> Sure, this is a hack.  Even worse: not documented.  [...]

I meant: not very well documented.  Indeed:

    $ ./bootstrap.sh --help
    Usage: ./bootstrap.sh [OPTIONS] [ACLOCAL OPTIONS]
    Options:
      --version=VER
      --date-version
      --help
    aclocal options usually look like:
      -I /usr/share/libtool/libltdl

-- 
Rafael

Re: [Plplot-devel] current supported toolset?

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

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

> Following up on Maurice's later comment: Rafael, would it be straightforward
> to supply a default for this -I option consisting of appending
> '../share/libtool/libltdl/' to the results of `which libtool`?  I believe
> such a default would take care of most if not all of our needs so we would
> could simply invoke ./bootstrap.sh without parameters most of the time.

Please, tell me what this shell snippet gives for you:

    prefix=`which libtool | sed 's:/bin/libtool::'`
    if test -n "$prefix" ; then
      acdir=${prefix}/share/libtool/libltdl
      if test -d $acdir ; then
        if test -f ${acdir}/aclocal.m4 ; then
          aclocal_opts="-I $acdir"
        fi
      fi
    fi
   echo aclocal_opts: $aclocal_opts    

If this works, I will integrate it into bootstrap.sh.

-- 
Rafael

Re: [Plplot-devel] current supported toolset?

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

On Tue, 25 Mar 2003, Maurice LeBrun wrote:

> Can anyone tell me what versions of autoconf/automake/libtool etc are
> working for you?  Today I tried a new checkout of plplot on Solaris
> and got a very long list of errors when running bootstrap.sh. E.g.


> [....]Aside: the first error about looking under /usr/share/libtool/libltdl is
> really strange.. I run everything local to my account --
>
> tonga$ which autoconf
> /home/mjl/local/SunOS/bin/autoconf
> tonga$ which automake
> /home/mjl/local/SunOS/bin/automake
> tonga$ which libtool
> /home/mjl/local/SunOS/bin/libtool
>
> I appear to be using:
>
> libtool-1.4.3
> autoconf-2.57
> automake-1.7

Those versions should be fine (identical versions to mine). But you have to
let bootstrap.sh know where a particular libltdl directory is (see
./bootstrap.sh --help).

From the information above, I think you have to run

./bootstrap.sh -I /home/mjl/local/SunOS/share/libtool/libltdl/

but you should check that that directory exists and is filled with the
correct files.  On my system

ls /home/software/autotools/install/share/libtool/libltdl/
COPYING.LIB  Makefile.in  acinclude.m4  config-h.in  configure.in  ltdl.h
Makefile.am  README       aclocal.m4    configure*   ltdl.c        stamp-h.in

Hope this information helps you get going with the latest PLplot, Maurice.

Following up on Maurice's later comment: Rafael, would it be straightforward
to supply a default for this -I option consisting of appending
'../share/libtool/libltdl/' to the results of `which libtool`?  I believe
such a default would take care of most if not all of our needs so we would
could simply invoke ./bootstrap.sh without parameters most of the time.

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] current supported toolset?

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

* Maurice LeBrun <mj...@ga...> [2003-03-25 06:13]:

> Can anyone tell me what versions of autoconf/automake/libtool etc are
> working for you?  Today I tried a new checkout of plplot on Solaris
> and got a very long list of errors when running bootstrap.sh. E.g.

Since you have access to a Solaris system, if you have not done it yet,
could you please test the release-candidate tarball?

> I appear to be using:
> 
> libtool-1.4.3
> autoconf-2.57
> automake-1.7

These are the versions that Alan, Joao, and I are using.
 
-- 
Rafael

Re: [Plplot-devel] current supported toolset?

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

* Maurice LeBrun <mj...@ga...> [2003-03-25 06:23]:

> Maurice LeBrun writes:
>  > Can anyone tell me what versions of autoconf/automake/libtool etc are
>  > working for you?  Today I tried a new checkout of plplot on Solaris
>  > and got a very long list of errors when running bootstrap.sh. E.g.
>  > 
>  > tonga$ ./bootstrap.sh 
>  > Running aclocal (GNU automake) 1.7...aclocal: couldn't open directory
>  > `/usr/share/libtool/libltdl': No such file or directory
>  >  done
>  > ...
>  > Aside: the first error about looking under /usr/share/libtool/libltdl is
>  > really strange.. I run everything local to my account --
> 
> Ahem.
> 
> tonga$ fgrep /usr/share *
> bootstrap.sh:  -I /usr/share/libtool/libltdl
> bootstrap.sh:aclocal_opts=${aclocal_opts:="-I /usr/share/libtool/libltdl"}
> 
> Not cool.  Surely there is a better way?

Sure, this is a hack.  Even worse: not documented.  Suggestions for
improvement are welcome.

For now, you can try:

    ./bootstrap.sh -I /home/mjl/local/SunOS/share/libtool/libltdl

or something similar.    
 
-- 
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-24 22:05]:

> That leaves the most obvious candidate for the ./get-drv-info segfault as
> the libltdl library that is used by ./get-drv-info and which comes with my
> libtool version (libtool-1.4.3 straight from FSF).  Besides the segfault
> there are also a number of valgrind "Conditional jump or move depends on
> uninitialised value(s)" associated with running ./get-drv-info on Linux.
> These message at best indicate the FSF guys haven't tried valgrind on their
> libltdl library and at worst may indicate a real memory management problem
> with that library. Rafael, we should do a test also with your libtool
> (patched Debian libtool-1.4.3) as soon as you finish the perl stuff and can
> make a tarball. Also, if that doesn't work, we should discuss the
> possibility of trying later libtool versions.
> 
> [...]
>
> * octave doesn't work because perl scripts refer to the wrong perl path
> #!/usr/bin/perl (rather than /usr/pkg/bin/perl) on netbsd.  One possibility
> is to change all our perl scripts so they all start with #!/usr/bin/env
> perl, but Rafael has decided a better way (and I agree) is simply to invoke
> perl explicitly by using $(PERL) scriptname_whatever throughout our
> Makefile.am files.

A new release-candidate tarball is availabale at the usual place
(http://people.debian.org/~rafael/plplot.html) which should fix the problems
above.  Let us hope that the libltdl library included by my Debian system
will do better than that of FSF, present in Alan's machine.

> BTW, the test week for our users is currently scheduled starting 12th April
> with the actual release scheduled on the 19th [...]

It is probably a better idea to announce widely and immediately the
availability of the release candidate tarballs, even if not all the
portability problems are fixed.  The sooner the users start trying it, the
sooner they will found bugs that we have overseen and the higher are the
chances that we keep our schedule in time. Why wait until April 12th?

-- 
Rafael

Re: [Plplot-devel] current supported toolset?

[Maurice L. <mj...@ga...>]

Maurice LeBrun writes:
 > Can anyone tell me what versions of autoconf/automake/libtool etc are
 > working for you?  Today I tried a new checkout of plplot on Solaris
 > and got a very long list of errors when running bootstrap.sh. E.g.
 > 
 > tonga$ ./bootstrap.sh 
 > Running aclocal (GNU automake) 1.7...aclocal: couldn't open directory
 > `/usr/share/libtool/libltdl': No such file or directory
 >  done
 > ...
 > Aside: the first error about looking under /usr/share/libtool/libltdl is
 > really strange.. I run everything local to my account --

Ahem.

tonga$ fgrep /usr/share *
bootstrap.sh:  -I /usr/share/libtool/libltdl
bootstrap.sh:aclocal_opts=${aclocal_opts:="-I /usr/share/libtool/libltdl"}

Not cool.  Surely there is a better way?

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

[Plplot-devel] current supported toolset?

[Maurice L. <mj...@ga...>]

Can anyone tell me what versions of autoconf/automake/libtool etc are
working for you?  Today I tried a new checkout of plplot on Solaris
and got a very long list of errors when running bootstrap.sh. E.g.

tonga$ ./bootstrap.sh 
Running aclocal (GNU automake) 1.7...aclocal: couldn't open directory
`/usr/share/libtool/libltdl': No such file or directory
 done
Running autoheader (GNU Autoconf) 2.57... done
Running automake (GNU automake) 1.7...configure.ac: `AM_INIT_AUTOMAKE' must be
used
automake: no proper implementation of AM_INIT_AUTOMAKE was found,
automake: probably because aclocal.m4 is missing...
automake: You should run aclocal to create this file, then
automake: run automake again.
configure.ac: installing `./install-sh'
configure.ac: installing `./mkinstalldirs'
configure.ac: installing `./missing'
Makefile.am:24: enable_dyndrivers does not appear in AM_CONDITIONAL
Makefile.am:31: required directory ./libltdl does not exist
bindings/Makefile.am:26: enable_tcl does not appear in AM_CONDITIONAL
bindings/Makefile.am:30: enable_tk does not appear in AM_CONDITIONAL
bindings/Makefile.am:34: enable_tkwin does not appear in AM_CONDITIONAL
...

Aside: the first error about looking under /usr/share/libtool/libltdl is
really strange.. I run everything local to my account --

tonga$ which autoconf
/home/mjl/local/SunOS/bin/autoconf
tonga$ which automake
/home/mjl/local/SunOS/bin/automake
tonga$ which libtool
/home/mjl/local/SunOS/bin/libtool

I appear to be using:

libtool-1.4.3
autoconf-2.57
automake-1.7

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

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

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

Here is the current status of plplot on netbsd.

There is one issue that is a real showstopper for netbsd (and perhaps other
unices).  The ./get-drv-info helper application segfaults when it tries to
obtain information about the xwin driver.  This is a really quite simple
routine that works for all other drivers (although I don't have a chance to
try it on tk because of the issue below).

There is nothing obviously wrong with the xwin.so linking.  When I look for
undefined symbols using nm -u, I can spot obvious libX11, libm, and
libplplot symbols, plus a very few I don't recognize.  However, those
libraries are all linked in, and there are no obvious error or warning
messages associated with the linking process (which I believe there would be
if another library needed to be specified by the link to resolve some
undefined symbols).

That leaves the most obvious candidate for the ./get-drv-info segfault as
the libltdl library that is used by ./get-drv-info and which comes with my
libtool version (libtool-1.4.3 straight from FSF).  Besides the segfault
there are also a number of valgrind "Conditional jump or move depends on
uninitialised value(s)" associated with running ./get-drv-info on Linux.
These message at best indicate the FSF guys haven't tried valgrind on their
libltdl library and at worst may indicate a real memory management problem
with that library. Rafael, we should do a test also with your libtool
(patched Debian libtool-1.4.3) as soon as you finish the perl stuff and can
make a tarball. Also, if that doesn't work, we should discuss the
possibility of trying later libtool versions.

Here are some additional issues that need to be addressed but which I can
bypass for now using --disable-tcl --without-freetype --disable-octave

* tcl/tk does not work because of the tcl/tk configuration design problems I
described here previously (and which I hope Maurice can help to sort out).

* freetype does not work because ft2build.h (which is #included by our
plfreetype software) apparently is not part of the netbsd distribution of
freetype2 (version 2.1.3 which is certainly pretty up-to-date).  I suspect
this is a deprecated file in any case since all it seems to do is #include
<freetype/config/ftheader.h>.  Andrew, do you forsee any problem if we replace
#include <ft2build.h> by #include <freetype/config/ftheader.h> in
plfreetype.h?

* octave doesn't work because perl scripts refer to the wrong perl path
#!/usr/bin/perl (rather than /usr/pkg/bin/perl) on netbsd.  One possibility
is to change all our perl scripts so they all start with #!/usr/bin/env
perl, but Rafael has decided a better way (and I agree) is simply to invoke
perl explicitly by using $(PERL) scriptname_whatever throughout our
Makefile.am files.

So the netbsd score is 3 avoided problems (all of which could be sorted out
quickly) and one showstopper.  If there is some adventurous soul here, who
would like to help out with the showstopper problem, it would be most
interesting to see whether there are segfaults with get-drv-info on any
other Linux or Unix platform.  Joao, you have voiced a few concerns for
OSF1, but they don't seem to involve get-drv-info.  Can you please confirm
that helper application is working well (especially for xwin and tk) for
OSF1 as well as SuSe?

BTW, the test week for our users is currently scheduled starting 12th April
with the actual release scheduled on the 19th so I think it is time in any
case for other developers besides Joao and me to start doing some testing of
the CVS snapshot tarballs on all platforms they have access to.  Ideally, we
would have all known portability issues solved on the platforms accessible
to us as a group before our users put the release candidate tarball through
its paces during test week.

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
__________________________

[Plplot-devel] tcl configuration problem on netbsd

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

Hi Maurice:

I have the following problem on netbsd.  The tcl libraries are installed
as the following files:

ls /usr/pkg/lib/libtcl*
/usr/pkg/lib/libtcl83.a                 /usr/pkg/lib/libtcl83.so.1
/usr/pkg/lib/libtcl83.la                /usr/pkg/lib/libtcl83.so.1.0
/usr/pkg/lib/libtcl83.so                /usr/pkg/lib/libtclstub83.a

I cannot specify TCLLIBDIR=/usr/pkg/lib, because then TCLLIBSTR is set (by
default) to -ltcl (rather than the correct -ltcl83) with the result that the
tcl libraries are not found on netbsd.  (I think one of our 5.2.0 users had
a similar problem on another Unix.)

There is also a quite similar problem for Tk configuration; if you specify
TKLIBDIR as an environment variable TKLIBSTR takes on the wrong (default)
value.

Two questions:

* Is there any workaround (environment variable to set or whatever) to deal
with these tcl/tk issues for the present configuration system?

* Could you give us some help/advice in fixing up our present tcl/tk
configuration system so it can handle such tcl/tk issues across the various
Unix platforms for the forthcoming 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 software
package (plplot.org).

__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] AC_CHECK_FUNC(isnan,... fails

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

* João Cardoso <jc...@fe...> [2003-03-24 20:11]:

> AC_CHECK_FUNC(isnan, ...
> or
> AC_CHECK_FUNCS(isnan isinf finite)
> 
> fails to detect isnan,... under OSF, as these functions are in libm and 
> configure don't add -lm to the compile command.
> isnan() and finite() are declared in math.h in this system.
> 
>  Is there a fast cure for this?

Yes, just put:

   AC_CHECK_LIB(m, sin)

Just before the AC_CHECK_FUNC[S] above.  (Not fully tested.)

-- 
Rafael

Re: [Plplot-devel] AC_CHECK_FUNC(isnan,... fails

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

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

>
>
> Hi,
>
> AC_CHECK_FUNC(isnan, ...
> or
> AC_CHECK_FUNCS(isnan isinf finite)
>
> fails to detect isnan,... under OSF, as these functions are in libm and
> configure don't add -lm to the compile command.
> isnan() and finite() are declared in math.h in this system.
>
>  Is there a fast cure for this?

I am no expert, but I figured out how to do something similar for libgd
a while ago where I was testing whether libgd supported jpeg or not.

Have a look at sysloc.in where AC_TRY_LINK_FUNC is invoked on line 250 and
set up in the lines before.

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] configure "fails" on dec/OSF

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

Hi,

After configure and "make dist" on a linux system, unpacking on a 
alphaev6-dec-osf4.0f and running configure gives this error:

...
checking for gcc option to accept ANSI C... none needed
checking build system type... ./config.guess: umask: `7077' is not an 
octal number from 000 to 777
config.guess: cannot create /tmp/config-guess-28457
alphaev6-dec-osf4.0f
...

But configure continues and finish. Is this error part of configure 
attempt to detect the system it is running on?

Joao

[Plplot-devel] AC_CHECK_FUNC(isnan,... fails

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

Hi,

AC_CHECK_FUNC(isnan, ...
or
AC_CHECK_FUNCS(isnan isinf finite)

fails to detect isnan,... under OSF, as these functions are in libm and 
configure don't add -lm to the compile command.
isnan() and finite() are declared in math.h in this system.

 Is there a fast cure for this?

Thanks,
Joao

[Plplot-devel] Cross-platform portability issue fixups with PLplot

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

An acquaintance in our Victoria LUG has been kind enough to give me a shell
account on his netbsd box for testing the recent CVS snapshot tarballs that
Rafael has been generating at http://people.debian.org/~rafael/plplot.html.
I haven't yet been able to get very far because it turns out there are a lot
of Unix portability issues that need to be resolved.

I have identified and fixed such issues (use of deprecated values.h) in
lib/csa and lib/nn, Rafael has fixed others (empty for loops which some
older bourne shells don't like), and Rafael is working on yet more issues
that have been identified (generally, Gnu Makeism's that have crept into the
Makefile.am files). Once those and any other Unix portability issues
identified when I get deeper into the netbsd build) are sorted out, I will
let you know on list here. That would be a good opportunity to try PLplot on
other unices to see if there are any additional portability issues that need
to be addressed.

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
__________________________