plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] New way of getting device info from dyndrivers

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

On Tuesday 04 February 2003 21:37, Rafael Laboissiere wrote:
> Preamble
> =3D=3D=3D=3D=3D=3D=3D=3D
>
> The big recent cvs commit regarding the dyndrivers database was on the =
top
> of my TODO list.  It is a necessary step towards clean
> configuration/building and also packaging for Debian.
>
> I am not yet completely happy with my implementation, but my changes
> (apparently) did not break PLplot.  My simple test script succeeded, at
> least.  I am committing without previous discussion here because, as Al=
an
> uses to say, getting novelties in cvs HEAD is the best way to foster
> discussions.

That's true, but the target should be to get a full-working 5.2.1, that s=
hould=20
be, in my opinion, a bug-correcting release.
Introducing such stuff can compromise it.
But we have not defined what 5.2.1 should be, and I'm too conservative.

I have myself lots of new stuff, and I'm refraining myself to commit them=
=2E I=20
hope that 5.2.2 or even 5.3.0 follows shortly.

>
> The Problem
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> The way PLplot used to get information about the available devices prov=
ided
> by the dyndrivers was through the DATA_DIR/drivers.db file.  This file =
was
> generated at configuration time and parsed when the library was
> initialized.
>
> This approach has two drawbacks:
>
> 1) Information about the devices are scattered in different places (nam=
ely
>    in the driver source file and in configure.ac).  This is ugly and ma=
y
>    result in unnecessary maintenance burden.
>
> 2) Since the list of available devices is hardcoded in the drivers.db i=
t is
>    almost impossible to do clean packaging of Plplot.  In Debian, for
>    instance, packaging is granular in order to reduce the dependencies:
>    plplot-xwin, plplot-tk, plplot-gd, etc.  Users can install a subset =
of
>    the available packages at will.  However, they will always get the f=
ull
>    list of available devices when plinit is called.  That is not a crit=
ical
>    problem, but annoying.
>
>
> The Solution
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> I have elaborated a full fix for this problem, but I just committed an
> intermediary solution for it.  Here is how it works:
>
> 1) drivers.db does not exist anymore.
>
> 2) In each driver file, there is a global declaration like this:
>
>    char* DEVICE_INFO_gd =3D "jpeg:JPEG file:0:gd:40:jpeg\n"
>                           "png:PNG file:0:gd:39:png";

OK, but we need a registration text file, manually maintained, to guide n=
ew=20
drivers writers on how to obtain (and register) new ids for the new drive=
rs.=20

>
>    containing the entries that used to go into drivers.db. If a driver
>    provides more than one device, their entries must be separated by a
>    newline character ('\n').
>
> 3) When the library is initialized, if dyndrivers are enabled, the driv=
ers
>    directory is scanned for the *.la files.  Each found driver is dlope=
ned
>    and the DEVICE_INFO_<driver> symbol is read and put in a temporary f=
ile.
>
> 4) This temporary file plays the role of the old drivers.db file.

Why is the tmp file needed? Why not keep the collected info in an interna=
l=20
structure?

> Noticed that I did minimal changes to Geoff's code in plcore.c.  In the
> plInitDispatchTable function, I replaced the initial code (where the
> drivers.db were scanned) by the scanning of the drivers directory descr=
ibed
> in point 3 above.

Ah, you use a tmp file just to reuse Geoff's code. But there is no reason=
 to=20
not change that also latter, right?

> Also, all references to drivers.db and DRIVERS_DB have disappeared from=
 the
> sources.
>
>
> Drawbacks and improvements
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
>
> I see two potential problems with my approach:
>
> 1) Portability.  I am using new libc functions (POSIX tmpfile, opendir,
>    readdir and closedir).  Although am I following the recommended
> procedure found in the Autoconf docs (i.e. using AC_HEADER_DIRENT and a
> couple of tests with HAVE_DIRENT_H), I am sure that there will be some
> weird system out there (MacIntosh, say) for which my code won't compile=
=2E=20
> If that happens, we have to port that part of the code.

Don't create the file :)

> 2) With my approach, I have to open all and every module before using t=
hem.
>    This may appear as a regression as regards the "cache file" approach
>    provided by the use of drivers.db.  In terms of performance, with ou=
r
>    current computer power, the overload is negligible.  However, as I w=
rote
>    above, my original design was much better, but harder to implement (=
of
>    course).  It looks like this:
>
>    a) Forget about that entries a la drivers.db.
>
>    b) In each driver file <driver>.c define symbols DEV_DESC_*, DEV_SEQ=
_*,
>       DEV_TAG_*, etc.  These symbols can be used when filling fields in
>       function plD_dispatch_init_<device>.  This would further reduce t=
he
>       maintenance problem due to duplication of information.
>
>    c) At build time (not configuration time), a small C program dlopen =
the
>       <driver>.c files,

You mean "open" and not dlopen(), right?

> get the symbols

No, you mean dlopen() the <driver>.so (I don't know the current suffix)

What do you really mean? Anyway, see bellow.

> described above and write the
>       associated device entries in <driver>.rc (or whichever name).
>
>    d) Those <driver>.rc are installed in the drivers directory, along w=
ith
>       the <driver>.la and <driver>.so files.
>
>    e) When PLplot is initialized, the <driver>.rc files are scanned.
>
>    If I have some time before the 5.2.1 release, I will try to implemen=
t
>    this idea.

I prefer the full dynamic one, i.e., reading the already build drivers. I=
=20
don't think that performance will suffer. Do you have some figures or onl=
y =20
feelings?

Your second idea implies that the small program that scans the source fil=
es=20
needs information from the configure step to know what drivers are desire=
d by=20
the user and supported by the system. This complicates matters.
With the first idea, by contrary, only already build drivers, i.e, user=20
desired and system supported, are scanned.

Also, with the second idea I think that the driver-ids (the magic numbers=
) can=20
go away -- ah, no, for historical reasons the xwin driver must be number =
one,=20
the tk driver number 2, etc. hmm, there is another solution for this but =
let=20
discuss it latter.

If performance is really an issue, then one could implements a mixing of =
the=20
two ideas: don't generate drivers.db at configure nor build time. At run =
time=20
if drivers.db does not exists, scan the drivers and build it. This way th=
e=20
performance loss will only occurs once.
If a new driver is latter added to the directory (not probable, but possi=
ble,=20
after all this is the only advantage of dyndrivers), one could first comp=
are=20
the time-stamp of all drivers versus the drivers.db file, and rebuild=20
drivers.db if a driver is more recent. Reading time-stamp is fast, I beli=
eve.

Joao

Re: [Plplot-devel] New way of getting device info from dyndrivers

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

On Tuesday 04 February 2003 23:11, Alan W. Irwin wrote:
> On Tue, 4 Feb 2003, Rafael Laboissiere wrote:
=2E..
> > I also noticed that the
> > pstex entry was wrongly written in drivers.db.  Apparently, this bug =
have
> > never bothered our users...
>
> I have forgotten the details, but IIRC, I checked that drivers.db anoma=
ly
> before, and I am pretty sure it is necessary in order for pstex to work=
=2E
> Something to do with the way pstex depends on ps or vice versa.
>
> Joao, do you remember about this?

No. I only remember that the pstex configuration changed a couple of time=
s.
The pstex needs the ps driver, directly calling the ps driver entry point=
s.

If it works with Rafael changes, that's fine for me. For a quick test use=
 any=20
C example and the scripts/pstex2eps script to generate an eps.

>
> Alan

Re: [Plplot-devel] New way of getting device info from dyndrivers

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

On Tue, 4 Feb 2003, Rafael Laboissiere wrote:
> 3) When the library is initialized, if dyndrivers are enabled, the drivers
>    directory is scanned for the *.la files.  Each found driver is dlopened
>    and the DEVICE_INFO_<driver> symbol is read and put in a temporary file.

Are you using "dlopen" in the generic sense here?  The actual call should
be to lt_dlopenext, and you have to be careful of the argument (follow
exactly what I did with drvnam and drvspec so the file name comes out exactly
the same to get it to work cross-platform).


>    c) At build time (not configuration time), a small C program dlopen the
>       <driver>.c files,

Same comment.  My initial use of lt_dlopenext worked fine on Linux but died
horribly on OSF1 until I made my final changes to the lt_dlopenext argument.

> Postscript
> ==========
>
> In doing my changes, I noticed that the following drivers have never had
> entries in drivers.db:  plbuf.c and next.c.  Does anyone know why?

IIRC next.c is completely unmaintained and kept in CVS only as an
encouragment for somebody, someday, to get it going again.

plbuf.c is not a driver in the traditional sense.  I believe it is in the
wrong directory and should be put in src instead.  It's code is put directly
into the libplplot library (see src/Makefile.am).

> I also noticed that the
> pstex entry was wrongly written in drivers.db.  Apparently, this bug have
> never bothered our users...

I have forgotten the details, but IIRC, I checked that drivers.db anomaly
before, and I am pretty sure it is necessary in order for pstex to work.
Something to do with the way pstex depends on ps or vice versa.

Joao, do you remember about this?

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] New way of getting device info from dyndrivers

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

Preamble
========

The big recent cvs commit regarding the dyndrivers database was on the top
of my TODO list.  It is a necessary step towards clean
configuration/building and also packaging for Debian.

I am not yet completely happy with my implementation, but my changes
(apparently) did not break PLplot.  My simple test script succeeded, at
least.  I am committing without previous discussion here because, as Alan
uses to say, getting novelties in cvs HEAD is the best way to foster
discussions.


The Problem
===========

The way PLplot used to get information about the available devices provided
by the dyndrivers was through the DATA_DIR/drivers.db file.  This file was
generated at configuration time and parsed when the library was initialized.

This approach has two drawbacks:

1) Information about the devices are scattered in different places (namely
   in the driver source file and in configure.ac).  This is ugly and may
   result in unnecessary maintenance burden.

2) Since the list of available devices is hardcoded in the drivers.db it is
   almost impossible to do clean packaging of Plplot.  In Debian, for
   instance, packaging is granular in order to reduce the dependencies:
   plplot-xwin, plplot-tk, plplot-gd, etc.  Users can install a subset of
   the available packages at will.  However, they will always get the full
   list of available devices when plinit is called.  That is not a critical
   problem, but annoying.


The Solution
============

I have elaborated a full fix for this problem, but I just committed an
intermediary solution for it.  Here is how it works:

1) drivers.db does not exist anymore.

2) In each driver file, there is a global declaration like this:

   char* DEVICE_INFO_gd = "jpeg:JPEG file:0:gd:40:jpeg\n"
                          "png:PNG file:0:gd:39:png";

   containing the entries that used to go into drivers.db. If a driver
   provides more than one device, their entries must be separated by a
   newline character ('\n').
   
3) When the library is initialized, if dyndrivers are enabled, the drivers
   directory is scanned for the *.la files.  Each found driver is dlopened
   and the DEVICE_INFO_<driver> symbol is read and put in a temporary file.

4) This temporary file plays the role of the old drivers.db file.

Noticed that I did minimal changes to Geoff's code in plcore.c.  In the
plInitDispatchTable function, I replaced the initial code (where the
drivers.db were scanned) by the scanning of the drivers directory described
in point 3 above.

Also, all references to drivers.db and DRIVERS_DB have disappeared from the
sources.


Drawbacks and improvements
==========================

I see two potential problems with my approach:

1) Portability.  I am using new libc functions (POSIX tmpfile, opendir,
   readdir and closedir).  Although am I following the recommended procedure
   found in the Autoconf docs (i.e. using AC_HEADER_DIRENT and a couple of
   tests with HAVE_DIRENT_H), I am sure that there will be some weird system
   out there (MacIntosh, say) for which my code won't compile.  If that
   happens, we have to port that part of the code.

2) With my approach, I have to open all and every module before using them.
   This may appear as a regression as regards the "cache file" approach
   provided by the use of drivers.db.  In terms of performance, with our
   current computer power, the overload is negligible.  However, as I wrote
   above, my original design was much better, but harder to implement (of
   course).  It looks like this:
   
   a) Forget about that entries a la drivers.db.
   
   b) In each driver file <driver>.c define symbols DEV_DESC_*, DEV_SEQ_*,
      DEV_TAG_*, etc.  These symbols can be used when filling fields in
      function plD_dispatch_init_<device>.  This would further reduce the
      maintenance problem due to duplication of information.
      
   c) At build time (not configuration time), a small C program dlopen the
      <driver>.c files, get the symbols described above and write the
      associated device entries in <driver>.rc (or whichever name).

   d) Those <driver>.rc are installed in the drivers directory, along with
      the <driver>.la and <driver>.so files.
      
   e) When PLplot is initialized, the <driver>.rc files are scanned.
   
   If I have some time before the 5.2.1 release, I will try to implement
   this idea. 
   

Postscript
==========

In doing my changes, I noticed that the following drivers have never had
entries in drivers.db:  plbuf.c and next.c.  Does anyone know why?

I introduced the DEVICE_INFO_<driver> symbol in all drivers listed in
variable EXTRA_LTLIBRARIES of drivers/Makefile.am.  I also noticed that the
pstex entry was wrongly written in drivers.db.  Apparently, this bug have
never bothered our users... 

-- 
Rafael

Re: [Plplot-devel] Re: Problems Installing Plplot-5.2.0 under AIX

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

On Tue, 4 Feb 2003, Joao Cardoso wrote:

> > Maurice, I believe you have had prior experience with AIX.  There are
> > no math calls in tclMatrix.c and matrixInit.c, but I am wondering if
> > (many!) unresolved math symbols in -ltcl8.3 are causing the link problem.

Thanks, Maurice, for answering that question separately.
>
> I think that the source of most problems is the link command used. On a
> previous report there were many plplot API entries that were missing,
> although the command line specifies -lplplot.

Actually, Joao, there has now been one further iteration and Don reports
that --disable-cxx --disable-f77 --disable-tcl builds fine on AIX.  There is
one other installation problem we are sorting out at the moment, but once
that is done, I am discussing a possible fix for tcl/tk with Maurice which I
hope that Don would be willing to test before 5.2.1.

The AIX fixes for f77 and C++ are not so obvious so we may have to put those
off until after 5.2.1.

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] Tests of recent commits

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

On Tuesday 04 February 2003 08:35, Rafael Laboissiere wrote:
> * Alan W. Irwin <ir...@be...> [2003-02-03 14:17]:
> > On Mon, 3 Feb 2003, Rafael Laboissiere wrote:
> > > > make[3]: Entering directory `/home/jcard/plplot/bindings/python'
> > > > python -o plplotcmodule_p_double.c -c++ -DPL_DOUBLE \
> > > > plplotcmodule.i
> > > > Unknown option: -o
> > >
> > > No idea about this.  Alan?
> >
> > The command should be
> >
> > $(SWIG) -python -o plplotcmodule_p_double.c -c++ -DPL_DOUBLE \
> >         plplotcmodule.i
> >
> > So I think his error message is caused because $(SWIG) is undefined f=
or
> > him, but I don't know the root cause of that problem. One possibility=
 is
> > the old autotools versions he is using. Another possibility is he may
> > have forgot to specify --enable-maintainer-mode for his ./configure
> > option.  I don't know whether that is essential or not after you have
> > done a make
> > maintainer-clean, but I suspect it is.
> >
> > What happens, Joao, for the latest stable autotools versions, clean
> > PLplot checkout, and --enable-maintainer-mode?
>
> Your diagnosis above related to the $(SWIG) variable is correct.  Howev=
er,
> the problem cannot be caused at all by the absence of the option
> --enable-maintainer-mode.  I introduced maintainer-mode in a recent com=
mit
> (by adding AM_MAINTAINER_MODE to configure.ac) but for now the only thi=
ng
> that is done in maintainer mode is the printing of a warning message ab=
out
> the unavailability of swig.
>
> To sum up: even with option --disable-maintainer-mode (or, equivalently=
, by
> omitting --enable-maintainer-mode), but with --enable-python, the swig
> checks are done, and the SWIG variable *must* be AC_SUBSTituted by eith=
er
> "swig" or "echo swig program not available #".
>
> I think that Joao should, first of all, update his AutoTools to the lat=
est
> versions, and then try to reproduce the bug.

Yes, I will do that, give me some more time :)
Joao

Re: [Plplot-devel] Tests of recent commits

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

* Alan W. Irwin <ir...@be...> [2003-02-03 14:17]:

> On Mon, 3 Feb 2003, Rafael Laboissiere wrote:
> 
> >
> > > make[3]: Entering directory `/home/jcard/plplot/bindings/python'
> > > python -o plplotcmodule_p_double.c -c++ -DPL_DOUBLE \
> > > plplotcmodule.i
> > > Unknown option: -o
> >
> > No idea about this.  Alan?
> 
> The command should be
> 
> $(SWIG) -python -o plplotcmodule_p_double.c -c++ -DPL_DOUBLE \
>         plplotcmodule.i
> 
> So I think his error message is caused because $(SWIG) is undefined for him,
> but I don't know the root cause of that problem. One possibility is the old
> autotools versions he is using. Another possibility is he may have forgot to
> specify --enable-maintainer-mode for his ./configure option.  I don't know
> whether that is essential or not after you have done a make
> maintainer-clean, but I suspect it is.
> 
> What happens, Joao, for the latest stable autotools versions, clean PLplot
> checkout, and --enable-maintainer-mode?

Your diagnosis above related to the $(SWIG) variable is correct.  However,
the problem cannot be caused at all by the absence of the option
--enable-maintainer-mode.  I introduced maintainer-mode in a recent commit
(by adding AM_MAINTAINER_MODE to configure.ac) but for now the only thing
that is done in maintainer mode is the printing of a warning message about
the unavailability of swig.

To sum up: even with option --disable-maintainer-mode (or, equivalently, by
omitting --enable-maintainer-mode), but with --enable-python, the swig
checks are done, and the SWIG variable *must* be AC_SUBSTituted by either
"swig" or "echo swig program not available #".

I think that Joao should, first of all, update his AutoTools to the latest
versions, and then try to reproduce the bug.

-- 
Rafael

Re: [Plplot-devel] Tests of recent commits

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

On Tuesday 04 February 2003 03:51, Maurice LeBrun wrote:
> Joao Cardoso writes:
>  > On Monday 03 February 2003 21:36, Rafael Laboissiere wrote:
>  > > * Rafael Laboissiere <lab...@ps...> [2003-02-03 21:35]:
>  > > > * Jo=E3o Cardoso <jc...@fe...> [2003-02-03 17:12]:
>  > > > > 2 - Also, when configure reaches libbltdl it does not uses the
>  > > > > configure cache, which can make configure faster:
>  > > >
>  > > > I will take a look at this.
>  > >
>  > > I did.  Give option --cache-file=3Dconfig.cache to ./configure.  T=
his
>  > > will be inherited by libltdl/configure, and many tests will be cac=
hed,
>  > > with improvements in speed.
>  >
>  > Thanks. Couldn't it be done by default?
>  > I use to see this feature enabled in other packages, although what
>  > autoconf info says about "`configure' uses no cache file ... to avoi=
d
>  > problems caused by accidental use of stale cache files."?
>
> I always turned off cache files by default under the old configuration
> scheme, because the risk just wasn't worth it.. i.e. I've been burned b=
y
> it.  If you reconfigure plplot using new command line flags the cache f=
ile
> MUST be invalidated or you will be burned too.  If this requirement can=
't
> be satisfied it should probably be left off.

OK,

Joao

Re: [Plplot-devel] Re: Problems Installing Plplot-5.2.0 under AIX

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

Alan W. Irwin writes:
 > On Mon, 3 Feb 2003, Don Spong wrote:
 > 
 > [...]
 > > gcc -shared -o .libs/libtclmatrix.so.5  tclMatrix.o matrixInit.o
 > > -L/usr/local/lib -ltcl8.3 -lc   -Wl,-bnoentry
 > > -Wl,-bexport:.libs/libtclmatrix.exp
 > > ld: 0711-317 ERROR: Undefined symbol: acos
 > > ld: 0711-317 ERROR: Undefined symbol: asin
 > > ld: 0711-317 ERROR: Undefined symbol: atan
 > > ld: 0711-317 ERROR: Undefined symbol: atan2
 > > ld: 0711-317 ERROR: Undefined symbol: ceil
 > > ld: 0711-317 ERROR: Undefined symbol: cos
 > > ld: 0711-317 ERROR: Undefined symbol: cosh
 > > ld: 0711-317 ERROR: Undefined symbol: exp
 > > ld: 0711-317 ERROR: Undefined symbol: floor
 > > ld: 0711-317 ERROR: Undefined symbol: fmod
 > > ld: 0711-317 ERROR: Undefined symbol: hypot
 > > ld: 0711-317 ERROR: Undefined symbol: log
 > > ld: 0711-317 ERROR: Undefined symbol: log10
 > > ld: 0711-317 ERROR: Undefined symbol: pow
 > > ld: 0711-317 ERROR: Undefined symbol: sin
 > > ld: 0711-317 ERROR: Undefined symbol: sinh
 > > ld: 0711-317 ERROR: Undefined symbol: sqrt
 > > ld: 0711-317 ERROR: Undefined symbol: tan
 > > ld: 0711-317 ERROR: Undefined symbol: tanh
 > > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
 > > collect2: ld returned 8 exit status
 > > make: 1254-004 The error code from the last command is 1.
 > 
 > Maurice, I believe you have had prior experience with AIX.  There are
 > no math calls in tclMatrix.c and matrixInit.c, but I am wondering if
 > (many!) unresolved math symbols in -ltcl8.3 are causing the link problem.

Uh.. -lm ?

Don't forget we have a record of all the flags used in the previous config
system down in cf/.  So:

$ grep lm cf/lib_sh_aix.in 
          $(SHLIB_LIBS) -lc -lm 2>ld.out
          $(SHLIB_LIBS) -lc -lm 2>ld.out
          $(SHLIB_LIBS) -lc -lm 2>ld.out


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

Re: [Plplot-devel] Tests of recent commits

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

Joao Cardoso writes:
 > On Monday 03 February 2003 21:36, Rafael Laboissiere wrote:
 > > * Rafael Laboissiere <lab...@ps...> [2003-02-03 21:35]:
 > > > * Jo=E3o Cardoso <jc...@fe...> [2003-02-03 17:12]:
 > > > > 2 - Also, when configure reaches libbltdl it does not uses the=

 > > > > configure cache, which can make configure faster:
 > > >
 > > > I will take a look at this.
 > >
 > > I did.  Give option --cache-file=3Dconfig.cache to ./configure.  T=
his will be
 > > inherited by libltdl/configure, and many tests will be cached, wit=
h
 > > improvements in speed.
 >=20
 > Thanks. Couldn't it be done by default?
 > I use to see this feature enabled in other packages, although what a=
utoconf=20
 > info says about "`configure' uses no cache file ... to avoid problem=
s caused=20
 > by accidental use of stale cache files."?

I always turned off cache files by default under the old configuration =
scheme,
because the risk just wasn't worth it.. i.e. I've been burned by it.  I=
f you
reconfigure plplot using new command line flags the cache file MUST be
invalidated or you will be burned too.  If this requirement can't be sa=
tisfied
it should probably be left off.

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

Re: [Plplot-devel] Re: Problems Installing Plplot-5.2.0 under AIX

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

On Tuesday 04 February 2003 00:01, Alan W. Irwin wrote:
> On Mon, 3 Feb 2003, Don Spong wrote:
>
> [...]
>
> > =09/bin/sh ../../libtool --mode=3Dlink gcc  -g -O2    -o
> > libtclmatrix.la -rpath /home/spongda/plplot-5.2.0/lib -version-info
> > 7:0:2 -rpath /home/spongda/plplot-5.2.0/lib -no-undefined
> > -L/usr/local/lib -ltcl8.3 tclMatrix.lo matrixInit.lo
> > mkdir .libs
> > rm -fr .libs/libtclmatrix.la .libs/libtclmatrix.* .libs/libtclmatrix.=
*
> > (cd . && ln -s tclMatrix.lo tclMatrix.o)
> > (cd . && ln -s matrixInit.lo matrixInit.o)
> > generating symbol list for `libtclmatrix.la'
> > /bin/nm -B  tclMatrix.o matrixInit.o   | sed -n -e 's/^.*[
> > =09]\([BCDT][BCDT]*\)[=09][
> > =09]*\(\)\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2\3 \3/p' | sed 's/.*
> > //' | sort | uniq > .libs/libtclmatrix.exp
> > gcc -shared -o .libs/libtclmatrix.so.5  tclMatrix.o matrixInit.o
> > -L/usr/local/lib -ltcl8.3 -lc   -Wl,-bnoentry
> > -Wl,-bexport:.libs/libtclmatrix.exp
=2E..
> > ld: 0711-317 ERROR: Undefined symbol: tan
> > ld: 0711-317 ERROR: Undefined symbol: tanh
> > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
> > information. collect2: ld returned 8 exit status
> > make: 1254-004 The error code from the last command is 1.
>
> Maurice, I believe you have had prior experience with AIX.  There are
> no math calls in tclMatrix.c and matrixInit.c, but I am wondering if
> (many!) unresolved math symbols in -ltcl8.3 are causing the link proble=
m.

I think that the source of most problems is the link command used. On a=20
previous report there were many plplot API entries that were missing,=20
although the command line specifies -lplplot.

Perhaps Don's AIX isn't fully supported by libtool? Although libtool *say=
s*=20
during configure that it *knows* how to build shared libs in the detected=
=20
system!

   checking build system type... powerpc-ibm-aix4.3.3.0
   ...
   checking whether the linker (/bin/ld) supports shared libraries... yes
   ...
   checking if libtool supports shared libraries... yes
  =20
I'm afraid that without a AIX system it will be difficult for us to trace=
 and=20
fix the problem.

>
> This may be related to our convoluted method of determining the tcl lin=
k
> line in sysloc.in.  Perhaps better cross-platform support would be
> automatic if we use what Rafael was recommending
> (/usr/share/aclocal/tcl.m4) as a replacement?
>
> Meanwhile, Don, to move by this, I suggest you disable our tcl front-en=
d.
> (--disable-tcl).

Yes,=20

1-Disable *everything*,=20
--disable-tcl --disable-tk --disable-itcl --disable-cxx --disable-f77 =20
--enable-dyndrivers --disable-static --enable-shared.
Only the C library will be build with shared libs and dynamic drivers. Do=
n't=20
forget to follow Alan's recomendations and unpack the sources fresh each =
time=20
-- or at least do a "make clean".

2-If the above don't work, the next step will be giving up of shared libs=
 and=20
build only static libs:
 --disable-tcl --disable-tk --disable-itcl --disable-cxx --disable-f77=20
--disable-shared

3-Don, you might need the fortran bindings, but if you can't compile the =
basic=20
C library there is no hope for you (for now, please be patient and wait f=
or=20
5.2.1)

Joao

Re: [Plplot-devel] Tests of recent commits

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

On Monday 03 February 2003 21:36, Rafael Laboissiere wrote:
> * Rafael Laboissiere <lab...@ps...> [2003-02-03 21:35]:
> > * Jo=E3o Cardoso <jc...@fe...> [2003-02-03 17:12]:
> > > 2 - Also, when configure reaches libbltdl it does not uses the
> > > configure cache, which can make configure faster:
> >
> > I will take a look at this.
>
> I did.  Give option --cache-file=3Dconfig.cache to ./configure.  This w=
ill be
> inherited by libltdl/configure, and many tests will be cached, with
> improvements in speed.

Thanks. Couldn't it be done by default?
I use to see this feature enabled in other packages, although what autoco=
nf=20
info says about "`configure' uses no cache file ... to avoid problems cau=
sed=20
by accidental use of stale cache files."?


Joao

[Plplot-devel] Re: Problems Installing Plplot-5.2.0 under AIX

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

On Mon, 3 Feb 2003, Don Spong wrote:

[...]
> 	/bin/sh ../../libtool --mode=link gcc  -g -O2    -o
> libtclmatrix.la -rpath /home/spongda/plplot-5.2.0/lib -version-info
> 7:0:2 -rpath /home/spongda/plplot-5.2.0/lib -no-undefined
> -L/usr/local/lib -ltcl8.3 tclMatrix.lo matrixInit.lo
> mkdir .libs
> rm -fr .libs/libtclmatrix.la .libs/libtclmatrix.* .libs/libtclmatrix.*
> (cd . && ln -s tclMatrix.lo tclMatrix.o)
> (cd . && ln -s matrixInit.lo matrixInit.o)
> generating symbol list for `libtclmatrix.la'
> /bin/nm -B  tclMatrix.o matrixInit.o   | sed -n -e 's/^.*[
> 	]\([BCDT][BCDT]*\)[	][
> 	]*\(\)\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2\3 \3/p' | sed 's/.*
> //' | sort | uniq > .libs/libtclmatrix.exp
> gcc -shared -o .libs/libtclmatrix.so.5  tclMatrix.o matrixInit.o
> -L/usr/local/lib -ltcl8.3 -lc   -Wl,-bnoentry
> -Wl,-bexport:.libs/libtclmatrix.exp
> ld: 0711-317 ERROR: Undefined symbol: acos
> ld: 0711-317 ERROR: Undefined symbol: asin
> ld: 0711-317 ERROR: Undefined symbol: atan
> ld: 0711-317 ERROR: Undefined symbol: atan2
> ld: 0711-317 ERROR: Undefined symbol: ceil
> ld: 0711-317 ERROR: Undefined symbol: cos
> ld: 0711-317 ERROR: Undefined symbol: cosh
> ld: 0711-317 ERROR: Undefined symbol: exp
> ld: 0711-317 ERROR: Undefined symbol: floor
> ld: 0711-317 ERROR: Undefined symbol: fmod
> ld: 0711-317 ERROR: Undefined symbol: hypot
> ld: 0711-317 ERROR: Undefined symbol: log
> ld: 0711-317 ERROR: Undefined symbol: log10
> ld: 0711-317 ERROR: Undefined symbol: pow
> ld: 0711-317 ERROR: Undefined symbol: sin
> ld: 0711-317 ERROR: Undefined symbol: sinh
> ld: 0711-317 ERROR: Undefined symbol: sqrt
> ld: 0711-317 ERROR: Undefined symbol: tan
> ld: 0711-317 ERROR: Undefined symbol: tanh
> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
> collect2: ld returned 8 exit status
> make: 1254-004 The error code from the last command is 1.

Maurice, I believe you have had prior experience with AIX.  There are
no math calls in tclMatrix.c and matrixInit.c, but I am wondering if
(many!) unresolved math symbols in -ltcl8.3 are causing the link problem.

This may be related to our convoluted method of determining the tcl link
line in sysloc.in.  Perhaps better cross-platform support would be automatic
if we use what Rafael was recommending (/usr/share/aclocal/tcl.m4) as a
replacement?

Meanwhile, Don, to move by this, I suggest you disable our tcl front-end.
(--disable-tcl).


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] Problems Installing Plplot-5.2.0 under AIX (fwd)

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

Alan W. Irwin writes:
 > Got this privately from Don Spong.
 > 
 > [...]
 > gcc -shared -o .libs/libplplotcxx.so.5  plstream.o  -Wl,-bnolibpath
 > -Wl,-blibpath:/home/spongda/plplot-5.2.0/src/.libs:/home/spongda/plplot-5.2.0/lib:/usr/lib:/lib
 > -L/home/spongda/plplot-5.2.0/src
 > -L/home/spongda/plplot-5.2.0/src/.libs -lplplot  -lc   -Wl,-bnoentry
 > -Wl,-bexport:.libs/libplplotcxx.exp
 > ld: 0711-317 ERROR: Undefined symbol: cerr
 > ld: 0711-317 ERROR: Undefined symbol: .ostream::operator<<(char const *)
 > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
 > collect2: ld returned 8 exit status
 > 
 > Seems that cerr (and some other .ostream function?) used by our C++ front
 > end is missing from AIX.
 > 
 > For now, I have suggested the workaround of disabling our C++ front end to
 > Don, but does anybody have any ideas about a permanent solution that would
 > allow building our C++ front end on AIX?

Maybe add -lstdc++ to the link line.  This is not necessary on my RH7.3 box,
but I don't know about other gcc installations.

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

Re: [Plplot-devel] Tests of recent commits

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

On Mon, 3 Feb 2003, Rafael Laboissiere wrote:

>
> > make[3]: Entering directory `/home/jcard/plplot/bindings/python'
> > python -o plplotcmodule_p_double.c -c++ -DPL_DOUBLE \
> > plplotcmodule.i
> > Unknown option: -o
>
> No idea about this.  Alan?

The command should be

$(SWIG) -python -o plplotcmodule_p_double.c -c++ -DPL_DOUBLE \
        plplotcmodule.i

So I think his error message is caused because $(SWIG) is undefined for him,
but I don't know the root cause of that problem. One possibility is the old
autotools versions he is using. Another possibility is he may have forgot to
specify --enable-maintainer-mode for his ./configure option.  I don't know
whether that is essential or not after you have done a make
maintainer-clean, but I suspect it is.

What happens, Joao, for the latest stable autotools versions, clean PLplot
checkout, and --enable-maintainer-mode?

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] Tests of recent commits

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

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

> * João Cardoso <jc...@fe...> [2003-02-03 17:12]:
> > 2 - Also, when configure reaches libbltdl it does not uses the configure 
> > cache, which can make configure faster:
> 
> I will take a look at this.

I did.  Give option --cache-file=config.cache to ./configure.  This will be
inherited by libltdl/configure, and many tests will be cached, with
improvements in speed.

-- 
Rafael

Re: [Plplot-devel] Tests of recent commits

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

* João Cardoso <jc...@fe...> [2003-02-03 17:12]:

> We could then deploy the script on the several platforms once a day 
> during the busy pre-release period or whenever major configurations 
> changes occur. The script  should do a cvs checkout and several 
> configure/make/test phases, sending the results by mail to the list (or 
> the user).

Nice idea.  For testing the building system for all combinations of
double/single precision and static/dynamic drivers, I wrote such a script.
I will eventually commit it the the scripts directory.

> Running automake (GNU automake) 1.6.3...configure.ac:425: `automake 
> requires `AM_CONFIG_HEADER', not `AC_CONFIG_HEADER'
>  done

Please, use the latest version of automake (1.7).

> 2 - Also, when configure reaches libbltdl it does not uses the configure 
> cache, which can make configure faster:

I will take a look at this.

> make[3]: Entering directory `/home/jcard/plplot/bindings/python'
> python -o plplotcmodule_p_double.c -c++ -DPL_DOUBLE \
> plplotcmodule.i
> Unknown option: -o

No idea about this.  Alan?

-- 
Rafael

[Plplot-devel] Problems Installing Plplot-5.2.0 under AIX (fwd)

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

Got this privately from Don Spong.

[...]
gcc -shared -o .libs/libplplotcxx.so.5  plstream.o  -Wl,-bnolibpath
-Wl,-blibpath:/home/spongda/plplot-5.2.0/src/.libs:/home/spongda/plplot-5.2.0/lib:/usr/lib:/lib
-L/home/spongda/plplot-5.2.0/src
-L/home/spongda/plplot-5.2.0/src/.libs -lplplot  -lc   -Wl,-bnoentry
-Wl,-bexport:.libs/libplplotcxx.exp
ld: 0711-317 ERROR: Undefined symbol: cerr
ld: 0711-317 ERROR: Undefined symbol: .ostream::operator<<(char const *)
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: ld returned 8 exit status

Seems that cerr (and some other .ostream function?) used by our C++ front
end is missing from AIX.

For now, I have suggested the workaround of disabling our C++ front end to
Don, but does anybody have any ideas about a permanent solution that would
allow building our C++ front end on AIX?

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] Tests of recent commits

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

On Sunday 02 February 2003 23:11, Alan W. Irwin wrote:
| "This change has been quickly tested in all the combinations of with-
| vs. without-double and enable- vs. disable-dyndrivers.  More
| extensive tests need to be done, though."
|
| I took that to heart.  I tested all of Rafael's recent changes except
| the very last one (removing some additional cruft from
| drivers/Makefile.am which was committed after I started my tests).=20
| In all cases I built all front ends and all drivers except the
| linuxsvga one.  For the combination of double+dynamic drivers I did
| the usual non-interactive test (plplot-test.sh) as well as fairly
| extensive interactive tests.  For the other 3 combinations
| (double+static, single+dynamic, single+static) I simply made sure I
| could build and install plplot and run plplot-test.sh (the
| non-interactive tests) without errors.

It looks like we need a compile-farm script to exercise all major=20
options conbinations on the several platforms that are available to us=20
:).
We could then deploy the script on the several platforms once a day=20
during the busy pre-release period or whenever major configurations=20
changes occur. The script  should do a cvs checkout and several=20
configure/make/test phases, sending the results by mail to the list (or=20
the user).

-------------------------------------------------------------------------=
--------------------
1 - Meanwhile, I got the following warning:

[jcard@feup] ./bootstrap.sh && ./configure --enable-octave=20
--enable-dyndrivers --with-double --disable-static=20
--prefix=3D/usr/local/test
Running aclocal (GNU automake) 1.6.3... done
Running libtoolize (GNU libtool) 1.4.2... done
Running autoheader (GNU Autoconf) 2.53...autoheader: `config.h.in' is=20
unchanged
 done
Running automake (GNU automake) 1.6.3...configure.ac:425: `automake=20
requires `AM_CONFIG_HEADER', not `AC_CONFIG_HEADER'
 done
Running autoconf (GNU Autoconf) 2.53... done
No defaults file found, performing full configure.
=2E..

-------------------------------------------------------------------------=
--------------------
2 - Also, when configure reaches libbltdl it does not uses the configure=20
cache, which can make configure faster:

configure: configuring in libltdl
configure: running /bin/sh './configure' --prefix=3D/usr/local/test  [...=
]=20
--cache-file=3D/dev/null <----------------

-------------------------------------------------------------------------=
--------------------
3 - Also after a "make maintainer-clean", make stops with

make[3]: Entering directory `/home/jcard/plplot/bindings/python'
python -o plplotcmodule_p_double.c -c++ -DPL_DOUBLE \
plplotcmodule.i
Unknown option: -o

[jcard@feup] python -V
Python 2.2.1

[jcard@feup] swig -version

SWIG Version 1.3.17u-20021204-1728

Joao

Re: [Plplot-devel] "_drv" in dyndrv module names

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

* Alan W. Irwin <ir...@be...> [2003-02-03 07:36]:

> On Mon, 3 Feb 2003, Rafael Laboissiere wrote:
> 
> > Can anybody tell me why "_drv" is appended to the file name of dynamically
> > driver modules and why that is necessary?
> >
> > It looks like cruft to me and I am going to clean that up, if nobody comes
> > with good arguments.
> 
> I don't care one way or the other.

Okay, this will be the next cleanup.  Boy, I am getting my hands dirty... :-)

-- 
Rafael

Re: [Plplot-devel] "_drv" in dyndrv module names

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

On Mon, 3 Feb 2003, Rafael Laboissiere wrote:

> Can anybody tell me why "_drv" is appended to the file name of dynamically
> driver modules and why that is necessary?
>
> It looks like cruft to me and I am going to clean that up, if nobody comes
> with good arguments.

I don't care one way or the other.

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] "_drv" in dyndrv module names

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

Can anybody tell me why "_drv" is appended to the file name of dynamically
driver modules and why that is necessary?

It looks like cruft to me and I am going to clean that up, if nobody comes
with good arguments.

-- 
Rafael

[Plplot-devel] Tests of recent commits

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

"This change has been quickly tested in all the combinations of with- vs.
without-double and enable- vs. disable-dyndrivers.  More extensive tests
need to be done, though."

I took that to heart.  I tested all of Rafael's recent changes except the
very last one (removing some additional cruft from drivers/Makefile.am which
was committed after I started my tests).  In all cases I built all front
ends and all drivers except the linuxsvga one.  For the combination of
double+dynamic drivers I did the usual non-interactive test (plplot-test.sh)
as well as fairly extensive interactive tests.  For the other 3 combinations
(double+static, single+dynamic, single+static) I simply made sure I could
build and install plplot and run plplot-test.sh (the non-interactive tests)
without errors.

Anyhow, on Debian woody the recent cruft removal and simplification is still
giving us a working software build and install and working examples for a
wide variety of circumstances.

Please let us know the story on other platforms as well.

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] plplot-5.2.0 / redhat 8.0 (fwd)

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

On Sun, 2 Feb 2003, Joao Cardoso wrote:

> This does not happens with me on a freshly installed RH-8.0 nor in my
> SuSE-8.1, but happened in another SuSE-8.1 and now in another RH-8.0!

It's great you have finally been able to confirm this elusive error, Joao,
for at least some X setups.

Question for you (and Matt as well).  For those cases where you are having X
problems with PLplot can you run other X applications (e.g., xterm) without
problems?  I assume that is the case, but it should be confirmed.  If xterm
works but, e.g., ./x01c -dev xwin does not, it would be most interesting to
compare the valgrind results in the two cases to see if this elusive problem
has anything to do with memory management difficulties.

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] plplot-5.2.0 / redhat 8.0 (fwd)

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

Alan W. Irwin writes:
 > ---------- Forwarded message ----------
 > Date: Fri, 31 Jan 2003 15:49:35 -0600 (CST)
 > From: Matt Newville <new...@ca...>
 > To: Alan W. Irwin <ir...@be...>
 > Subject: plplot-5.2.0 / redhat 8.0
 > 
 > [...]
 > In addition, './x01c -dev tk' reports:
 > 
 >  Plplot library version: 5.2.0
 >  X server insecure (must use xauth-style authorization); command
 >  ignored
 >      while executing
 >  "send $client "set server_name [list $server_name]""
 >      (procedure "plserver_link_init" line 25)
 >      invoked from within
 >  "plserver_link_init"
 >      (procedure "plserver_init" line 85)
 >      invoked from within
 >  "plserver_init"
 > 
 > I am tunneling X through ssh, but that's pretty standard practice
 > these days...

I usually see this when someone has xhost-style access enabled, even though
you may not be using it (since you're coming in through ssh).  Check to
make sure the xhost command gives only:

$ xhost
access control enabled, only authorized clients can connect

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