plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Re: debian plplot & octave-plplot-0.3

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

* Christophe TROESTLER <deb...@ti...> [2003-02-12 19:49]:

> Well, if I may say my opinion, you do not want the plplot package to
> depend on octave, so it is good to keep octave related stuff in a
> separate package.

This will be the case.

> Talking about the Debian packages, « plplot-tcl » which is supposed to
> contain the tk driver does not.

I am doing a big overhaul in the Debian packages and they will be available
when the next version of PLplot will be released (5.2.1 or 5.3.0).  They
will be much improved.  All the tk drivers will be included oin plplot-tcl.

> A plplot-examples package would be nice.

The examples will be distributed with their respective packages:

  libplplot-dev: /usr/share/doc/libplplot5/examples/{c,c++,f77}
  python-plplot: /usr/share/doc/libplplot5/examples/python
  octave-plplot: /usr/share/doc/libplplot5/examples/octave
  plplot-tcl:    /usr/share/doc/libplplot5/examples/{tcl,tk}

-- 
Rafael

[Plplot-devel] Re: debian plplot & octave-plplot-0.3

[Christophe T. <deb...@ti...>]

On Wed, 12 Feb 2003, João Cardoso <jc...@fe...> wrote:
> 
> Rafael & David, does the debian octave-plplot-0.3 package still
> makes sense? Specially if it is outdated?

Well, if I may say my opinion, you do not want the plplot package to
depend on octave, so it is good to keep octave related stuff in a
separate package.

Talking about the Debian packages, « plplot-tcl » which is supposed to
contain the tk driver does not.  I can see that a version of the lib
with the tk driver enabled is compiled but for some reason does not
end up in the package.  Also, are they reasons why the debian package
is not compiled with
	--with-double 	(if there are no issues with speed, are there??)
	--enable-png 	(couldn't make it to work)

A plplot-examples package would be nice.

BTW, there are some problems when compiling plplot-5.2.0 with the
option --with-double, make ends with the message:

	...
	make[1]: *** No rule to make target `dg300d.lo', needed by `libplplotdrv.la'.  Stop.
	make[1]: Leaving directory `/tmp/PLPLOT/plplot-5.2.0/drivers'
	make: *** [all-recursive] Error 1


Finally, if I issue « xhost +local: », the Tk driver crashes with:

	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"

Why?  (There is no problem with the xwin driver.)

Cheers,
ChriS

Re: [Plplot-devel] tcl/tk driver build results on Solaris : Needs Help

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

I don't have access to the combination of tcl/tk and solaris, but I believe
Maurice got tcl/tk to work on solaris for plplot-5.2.0.  I don't know the
details of what he had to do to get it to work.  My understanding is Maurice
is completely under new job pressure at the moment, but eventually I hope he
will be able to answer you.

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] Re: top-level Makefile.am changes

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

* Alan W. Irwin <ir...@be...> [2003-02-12 08:31]:

> Rafael, I am concerned about your recent change to the top-level Makefile.am
> [...]

That has already been fixed in cvs.  Sorry for the screwup.

-- 
Rafael

[Plplot-devel] top-level Makefile.am changes

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

Rafael, I am concerned about your recent change to the top-level Makefile.am
since I don't see how static drivers could possibly work with it starting
from a clean checkout with no old drivers convenience library (possibly
configured differently from what you want in the new build) left over from
the last build.

All my experiments in December indicated it was absolutely essential to
build the static drivers before libplplot (since in that case the drivers
convenience library built in drivers becomes part of libplplot). Therefore,
for static drivers the directory order in SUBDIRS *must* have drivers before
src. Your changes have broken that rule for the static drivers case (in fact
the drivers directory is not mentioned at all) so I don't see how the
drivers convenience library is going to be available to add into libplplot
when you are building libplplot.

I haven't done this myself so I may be missing something, but my prediction
is if you start from a clean checkout or run make clean before your test
(which should get rid of any old convenience library that will cover up this
error), I think you will quickly see why I am concerned.

I also don't understand your commit comment about drivers must come after
bindings since that already occurred for the previous Makefile.am for the
dynamic drivers case.  That cannot be the source of the bug you found if you
were installing dynamic drivers at the time.

Could you be more explicit about the exact error you have been trying to fix
with this change?  I may be able to find a fix that doesn't completely break
static drivers.

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
__________________________

---------- Forwarded message ----------
Date: Wed, 12 Feb 2003 04:12:42 -0800
From: Rafael Laboissiere <rla...@us...>
To: plp...@li...
Subject: [Plplot-cvs] CVS update notice (plplot/doc)

Update of /cvsroot/plplot/plplot/doc
In directory sc8-pr-cvs1:/tmp/cvs-serv30113/doc

Added Files:
	Makefile.am
Log Message:
[...]
2) Changed the order of directories in SUBDIRS, by putting "drivers" after
   "bindings".  This is _very_ important, because the old oreder triggers an
   error in the very specific situation: (a) the option --prefix=/usr is
   given to configure and (b) an old version of the PLplot package is
   already installed under /usr (this happened when I tried to build the
   Debian packages).

There is also another change in Makefile.am: instead of having the list of
directories duplicated in the enable_dyndrivers conditional, only the
DRIVERSDIR variable is set and then used later when setting the value of the
SUBDIRS variable. This is a cosmetic change, I know, but let us follow
William of Occam's maxim: "Pluralitas non est ponenda sine neccesitate".



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Plplot-cvs mailing list
Plp...@li...
https://lists.sourceforge.net/lists/listinfo/plplot-cvs

Re: [Plplot-devel] Re: [Plplot-general] refreshing with several streams [debian octave-plplot-0.3]

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

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

> Rafael & David, does the debian octave-plplot-0.3 package still makes 
> sense? Specially if it is outdated?

This package will be supplemented by the forthcoming octave-plplot-5.2.0
(or, more probably, octave-plplot-5.2.1), built directly from the upstream
sources.

The crappy package octave-plplot-0.3 should not be used in any case.
(I mean, its Debian packaging is crappy. Otherwise, PLplot_Octave is great!
:-)

-- 
Rafael

[Plplot-devel] Re: [Plplot-general] refreshing with several streams [debian octave-plplot-0.3]

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

On Wednesday 12 February 2003 15:21, Christophe TROESTLER wrote:
| On Wed, 12 Feb 2003, Jo=E3o Cardoso <jc...@fe...> wrote:
| > On Wednesday 12 February 2003 11:43, Christophe TROESTLER wrote:
| > > P.S.  BTW, the octave-plplot/README contains the following which
| > > does not seem to be accurate anymore:
| >
| > Where did you saw that? I have changed it in April 2001!
|
| In the Debian =AB unstable =BB package source (file
| octave-plplot-0.3.orig/README) ; see (download and send a mail to the
| maitainer at):
|
| http://packages.debian.org/unstable/math/octave-plplot.html
|
| I thought it was up-to-date since the plplot packages are.

Since plplot-5.0.3 (March 2001) that plplot_octave is integrated into=20
plplot. You should use the builtin version. Look in bindings/octave in=20
the source distribution.

Rafael & David, does the debian octave-plplot-0.3 package still makes=20
sense? Specially if it is outdated?

Thanks,
Joao

|
| ChriS

Re: [Plplot-devel] tcl/tk driver build results on Solaris : NeedsHelp

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

I am sorry about my ignorance, I am new to Solaris, and tcl/tk.

Where am I suppose to give this options ? I thought ./configure will take care
of every thing once I enable tcl/tk drivers.

Thanks for the help.

regards,
Pankaj.





----- Original Message -----
From: Vince Darley <vi...@sa...>
To: Pankaj Laddha <pa...@da...>
Cc: Joao Cardoso <jc...@fe...>; Alan W. Irwin <ir...@be...>;
PLplot development list <Plp...@li...>
Sent: Wednesday, February 12, 2003 7:41 PM
Subject: Re: [Plplot-devel] tcl/tk driver build results on Solaris : NeedsHelp


> On Wed, 12 Feb 2003, Pankaj Laddha wrote:
> > What is the cause of this erro? I tried building the source again by
commenting
> > "TclSetStartupScriptFileName, TclGetStartupScrip" functions in tclmain.c in
> > plplot\binding\tcl folder. It did not gave me any error. Is this the correct
> > way?
>
> Was everything built with -D USE_TCL_STUBS -D USE_TK_STUBS?
>
> I wouldn't worry too much about building the executables anyway, using
> 'load' is much better.
>
> > 2. After building the shared libraries, I tried to load them using tcl wish.
I
> > get following error
> >  ~/Plplot11 >wish8.4
> >  % load libtclmatrix.so
> > couldn't find procedure Tclmatrix_Init
>
> Try 'load libtclmatrix.so Matrix'
>
> (and make sure there is a symbol Matrix_Init in there)
>
> > % load /usr/pankaj/Plplot11/libtclmatrix.so
> > couldn't find procedure Tclmatrix_Init
> > % load /usr/pankaj/Plplot11/libplplot.so.5
> > couldn't find procedure Plplot_Init
>
> What symbols are in the .so?  I would look for 'Plplotter_Init'
>
> try
>
> load ....libplplplot.so.5 Plplotter
>
> cheers,
>
> Vince.
>
>

Re: [Plplot-devel] tcl/tk driver build results on Solaris : Needs Help

[Vince D. <vi...@sa...>]

On Wed, 12 Feb 2003, Pankaj Laddha wrote:
> What is the cause of this erro? I tried building the source again by commenting
> "TclSetStartupScriptFileName, TclGetStartupScrip" functions in tclmain.c in
> plplot\binding\tcl folder. It did not gave me any error. Is this the correct
> way?

Was everything built with -D USE_TCL_STUBS -D USE_TK_STUBS?

I wouldn't worry too much about building the executables anyway, using
'load' is much better.

> 2. After building the shared libraries, I tried to load them using tcl wish. I
> get following error
>  ~/Plplot11 >wish8.4
>  % load libtclmatrix.so
> couldn't find procedure Tclmatrix_Init

Try 'load libtclmatrix.so Matrix'

(and make sure there is a symbol Matrix_Init in there)

> % load /usr/pankaj/Plplot11/libtclmatrix.so
> couldn't find procedure Tclmatrix_Init
> % load /usr/pankaj/Plplot11/libplplot.so.5
> couldn't find procedure Plplot_Init

What symbols are in the .so?  I would look for 'Plplotter_Init'

try

load ....libplplplot.so.5 Plplotter

cheers,

Vince.

[Plplot-devel] tcl/tk driver build results on Solaris : Needs Help

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

Hi Alan, Joao,

I tried building Plplot 5.2.0 on Solaris 8, Active tcl/tk 8.4. Following is the
outcome of my try

1.
I get following error while building.
gcc -shared  tclAPI.lo tclMain.lo Pltk_Init.lo plframe.lo plr.lo tcpip.lo
tkMain.lo  -Wl,--rpath -Wl,/usr/pankaj/plplot-5.2.0/src/.libs -Wl,--rpath -Wl,/u
sr/pankaj/plplot-5.2.0/bindings/tcl/.libs -Wl,--rpath -Wl,/usr/local/lib  -L/usr
/ActiveTcl/lib -L/usr/pankaj/lib -ltcl8.4 -litcl3.2 -litk3.2 -ltk8.4 -L/usr/pank
aj/plplot-5.2.0/src
/usr/pankaj/plplot-5.2.0/src/.libs/libplplot.so -L/usr/pankaj/plplot-5.2.0/bindi
ngs/tcl
usr/pankaj/plplot-5.2.0/bindings/tcl/.libs/libtclmatrix.so   -lc  -Wl,-soname -W
l,libplplottcltk.so.5 -o .libs/libplplottcltk.so.5.2.0
/usr/ActiveTcl/lib/libtcl8.4.a(tclMain.o): In function
`TclSetStartupScriptFileName':
tclMain.o(.text+0xd4): multiple definition of `TclSetStartupScriptFileName'
tclMain.lo:/usr/pankaj/plplot-5.2.0/bindings/tcl/tclMain.c:142: first defined
here
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2/../../../../sparc-sun-solaris2.8
/bin/ld: Warning: size of symbol `TclSetStartupScriptFileName' changed from 44
to 24 in tclMain.o
/usr/ActiveTcl/lib/libtcl8.4.a(tclMain.o): In function
`TclGetStartupScriptFileName':
tclMain.o(.text+0xfc): multiple definition of `TclGetStartupScriptFileName'
tclMain.lo:/usr/pankaj/plplot-5.2.0/bindings/tcl/tclMain.c:164: first defined
here
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2/../../../../sparc-sun-solaris2.8
/bin/ld: Warning: size of symbol `TclGetStartupScriptFileName' changed from 44
to 40 in tclMain.o  collect2: ld returned 1 exit status

What is the cause of this erro? I tried building the source again by commenting
"TclSetStartupScriptFileName, TclGetStartupScrip" functions in tclmain.c in
plplot\binding\tcl folder. It did not gave me any error. Is this the correct
way?

2. After building the shared libraries, I tried to load them using tcl wish. I
get following error
 ~/Plplot11 >wish8.4
 % load libtclmatrix.so
couldn't find procedure Tclmatrix_Init
% load /usr/pankaj/Plplot11/libtclmatrix.so
couldn't find procedure Tclmatrix_Init
% load /usr/pankaj/Plplot11/libplplot.so.5
couldn't find procedure Plplot_Init

What can be the cause of the above error?

Can anybody help me to correct above problems. I have attached output logs of
configure, make and "make install" commands.

Thanks for any help.

regards,
Pankaj.

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

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

Thanks for your report on the test results.  Only a confirmation:

* Alan W. Irwin <ir...@be...> [2003-02-11 23:31]:

> [...] For now, though, it is best to avoid lt_dlclose (which I think the
> latest code from Rafael does).

Yes, it does.

-- 
Rafael

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

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

On Mon, 10 Feb 2003, Alan W. Irwin wrote:

> On Mon, 10 Feb 2003, Rafael Laboissiere wrote:
>
> > I can replicate this bug here.  The tkwin driver has probably some memory
> > management problems that make surface when lt_dlopenext/lt_dlclose are used.
> > That's weird, eh?
>
> I don't completely trust such interpretation....

I ran the valgrind test I suggested with lt_dclose uncommented and excluding
certain drivers.  This test was based on the 10 February software. The point
of this test is to look for memory management problems in the current set of
drivers with this old code rather than to look at the code Rafael just
checked in which (I believe) avoids making this test of
lt_dlopenext/lt_dlclose for every driver.

I found I got an absolutely clean valgrind result (except for well known
unfreed memory warnings at programme end) if I excluded xwin, tkwin, tk, and
gd.  Here was the list of drivers for the clean result:

ls ../../driversd/*.so
../../driversd/cgm.so*      ../../driversd/ljiip.so*
../../driversd/pstex.so*
../../driversd/dg300.so*    ../../driversd/null.so*    ../../driversd/tek.so*
../../driversd/hpgl.so*     ../../driversd/pbm.so*     ../../driversd/xfig.so*
../../driversd/impress.so*  ../../driversd/plmeta.so*
../../driversd/ljii.so*     ../../driversd/ps.so*

ldd shows that each of these is dynamically linked just to libplotd, libm,
libc, and libdl.  (cgm is also linked to the cd library, but that is a
static library so its a different case than gd, xwin, tkwin, and tk which
all are linked to extra dynamic libraries.)  If I added in gd, then I got
valgrind errors, but no segfault.  In a previous test with gd, xwin, and tkwin
(and tk?) we got segfaults.

There does seem to be a pattern developing that all drivers linked to extra
dynamic libraries have memory management problems of some kind that are
reported by valgrind.  I cannot draw a definitive conclusion from this, but
there is certainly the possibility that a libtool (libltdl) bug could be the
cause of this pattern, and I will certainly check gd, xwin, tkwin, and tk
again once a new version of libtool is released.  For now, though, it is
best to avoid lt_dlclose (which I think the latest code from Rafael does).
In this case (commented out lt_dlclose) we do get valgrind errors, but so
far (knock on wood for luck!) no segfaults have showed up.

I am completely sold on autotools as a convenient way to set up the
configuration of our software.  However, I am sure looking forward to the
day that autotools stabilizes!

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] Changing to a "release candidate" approach for 5.2.1.

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

My ideas on the release process have just been changed because of some
recent experience with extreme sensistivity to autotools versions.  Rafael's
versions are the same as the rest of ours (same base version numbers of
autoconf-2.57, automake-1.7.2, and libtool-1.4.3) except for patches applied
by Debian unstable.  However, it turns out one of those patches is critical
to making install relocatibility work (required for rpm and deb package
builds).  The DESTDIR parameter for make install works for Rafael's versions
of autotools (and will also work for the forthcoming libtool-1.5.0 release),
but not for the current unpatched FSF versions of autotools.

Although not directly related to cross-platform issues, this extreme
sensitivity of results to autotools versioning has convinced me of the
importance of using exactly the same autotools versions for our
cross-platform testing before the official release.  The autotools packages
are in a great state of flux at the moment, and I believe we have to adjust
to that fact for our release testing.

So I propose we make a release candidate tarball for 5.2.1 to be used for a
week of cross-platform testing before the release of 5.2.1. (Others have
urged this idea on me before for other reasons.  I don't particularly like
the implied additional complexity of the release process for such a small
project as ours, but I think it is necessary now because of the demonstrated
autotools versioning sensitivity.) The big advantage of the rc1 tarball
approach is testers will be working with exactly the same product regardless
of the autotools versions, swig versions, etc., that they have installed (or
not installed as the case may be).

The first week that is suitable for me is from April 12th to 19th, and it
turns out that is good for Rafael as well.  So if nobody has any objections
I propose to release the 5.2.1_rc1 tarball on the 12th with the final
release planned for the 19th.

Once we have final agreement on the date range of the test week please
reserve some time during that week on your calendars to do full testing of
PLplot on all platforms accessible to you.

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] About Tcl/tk drivers on Solaris

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

Hi All,

Has anybody tried buidling Plplot 5.2.0 on Solaris with Active tcl 8.4 version?
If yes, can you please share your results with me.

I plan to build Plplot5.2.0 on Solaris, so if anyone has tried this before,  let
me know if there are any changes I need to make.

Thanks for any help.

-Pankaj.

[Plplot-devel] Take 2: getting device info from dyndrivers

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

You probably noticed my last cvs commit.  Please, test.

-- 
Rafael

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

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

* Alan W. Irwin <ir...@be...> [2003-02-10 10:25]:

> I don't completely trust such interpretation because I have seen segfaults
> come and go depending on the placement (!) of print statements in the code.
> It is very hard to track down the real reason for segfaults until you use a
> tool like valgrind.
> 
> valgrind does indicate a problem with xwin even when lt_dlclose is
> commented out. So I suggest the best test is to uncomment lt_dlclose and
> exclude both xwin and tkwin.  Under those circumstances, then I would
> believe the above interpretation (problem somewhere in either xwin or tkwin
> or both) if the valgrind result is clean. Otherwise not.

I understand your point and I agree that such bugs are hard to be tracked
down.  However, the simple fact that dlopening/dlclosing tkwin.la _with
everything else kept equal_ makes it a quite good candidate for culprit.
Indeed, there are tones of malloc, calloc, ckcalloc, etc calls in the source
files (drivers/tk*.c and bindings/tk/*.c).  I cannot tell if they are
suspicious or not, though.

That said, it is possible that the code in xwin.c is equally bad...

At any rate:

> I don't have time to run this specific test now, but I will do so in the
> next few days if nobody else is curious enough to try it.

we are looking forward for the results of your valgrind tests.

-- 
Rafael

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

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

On Mon, 10 Feb 2003, Rafael Laboissiere wrote:

> * jc...@fe... <jc...@fe...> [2003-02-08 03:45]:
>
> > Try removing the tkwin driver from the install directory and uncommenting the
> > lt_dlclose (dlhand) in plcore.c that Rafael last cvs commit has commented.
> > x01c now works for me. tkwin is a bad-boy!
>
> I can replicate this bug here.  The tkwin driver has probably some memory
> management problems that make surface when lt_dlopenext/lt_dlclose are used.
> That's weird, eh?

I don't completely trust such interpretation because I have seen segfaults
come and go depending on the placement (!) of print statements in the code.
It is very hard to track down the real reason for segfaults until you use a
tool like valgrind.

valgrind does indicate a problem with xwin even when lt_dlclose is commented
out. So I suggest the best test is to uncomment lt_dlclose and exclude both
xwin and tkwin.  Under those circumstances, then I would believe the above
interpretation (problem somewhere in either xwin or tkwin or both) if the
valgrind result is clean. Otherwise not.

I don't have time to run this specific test now, but I will do so in the
next few days if nobody else is curious enough to try it.

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

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

On Monday 10 February 2003 15:44, Rafael Laboissiere wrote:
| Thanks for your useful report on library loading, Joao.
|
| * Jo=E3o Cardoso <jc...@fe...> [2003-02-10 15:19]:
| > Back to the drivers.rc solution, Rafael.
|
| I will give it a try one of these days.

If dlopen() is called with RTLD_NOW instead of RTLD_LAZY in the program=20
that I attached in my last e-mail, it work's OK (and its output is=20
similar to drivers.db).

But libtool docs says that RTLD_LAZY is used by default, so we might=20
have a problem. However, a comment in libtool-1.4.3/libltdl/ltdl.c=20
seems to indicate that this is an issue in some platforms:

/* We may have to define LT_LAZY_OR_NOW in the command line if we
   find out it does not work in some platform. */

With the small program is also easier to check for memory leaks with=20
valgrind, and most of the leaks come from libdl.
tmpfile() also contributes a bit.

Joao

PS-Also usefull are some environmental variables used by ld.so:
> man ld.so=20
> LD_DEBUG=3Dhelp ./po

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

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

Thanks for your useful report on library loading, Joao.

* João Cardoso <jc...@fe...> [2003-02-10 15:19]:

> Back to the drivers.rc solution, Rafael.

I will give it a try one of these days.


-- 
Rafael

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

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

* jc...@fe... <jc...@fe...> [2003-02-08 03:45]:

> Try removing the tkwin driver from the install directory and uncommenting the 
> lt_dlclose (dlhand) in plcore.c that Rafael last cvs commit has commented.
> x01c now works for me. tkwin is a bad-boy!

I can replicate this bug here.  The tkwin driver has probably some memory
management problems that make surface when lt_dlopenext/lt_dlclose are used.
That's weird, eh?

-- 
Rafael

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

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

On Monday 10 February 2003 07:13, Rafael Laboissiere wrote:
| * Maurice LeBrun <mj...@ga...> [2003-02-09 21:13]:
| > I've not been following the discussion very closely, but does this
| > mean that the code currently loads all dynamic drivers at startup
| > time?  If true, this seems against the spirit of dynamic drivers,
| > and adds unnecessarily to the memory used by the application.
|
| This is what I thought at the beginning and this is why I proposed
| the alternative design with the <driver>.rc files.  However here is
| what Joao wrote some days ago:
|
| * Jo=E3o Cardoso <jc...@fe...> [2003-02-07 14:51]:
| > Your concerns that dlopen() would load all libraries that a driver
| > needs does not apply, as this would only happens if some drivers
| > code is executed, which is not the case. As libtool's info says:
| >
| >     "Unresolved symbols in the module are resolved using
| >      its dependency libraries"
| >
| > As the symbols you are looking for are in the modules, no further
| > loading will occur.

Further, the libtool docs says that RTLD_LAZY is used when dlopen() is=20
effectively called.

But one thing is what the docs says, the other what is done.
What valgrind reports (in the attached program) is that libs are loaded:=20

=2E..
=3D=3D20614=3D=3D discard syms in /usr/lib/libjpeg.so.62.0.0 due to munma=
p()
=2E..

This seems to indicate that libjpeg was loaded, and latter unloaded,=20
even if not used, i.e., no code from it was executed and no symbol=20
belonging to it requested.

But the dlopen() man page also says:

      If  the  library  exports a routine named _init, then that
       code is executed  before  dlopen  returns.

and:

[jcard@feup] nm -p /usr/lib/libjpeg.so | fgrep _init
0001aaa0 T jpeg_mem_init
00001fd4 T _init

a _init function is defined in the library, meaning that it must be=20
executed. This must also happens for other libraries, as valgrind gives=20
the same kind of warning for other libraries.

Of course on most systems the libraries are not loaded, as they are=20
already loaded by the several programs the user is working with, but=20
there are of course exceptions.

Back to the drivers.rc solution, Rafael.

The attached program also shows that the bug we found does not seems to=20
be in the libtool library, but in the system's libdl, as the program=20
calls dl*() directly.

Joao

|
| I hope that this is true for all architectures.
|
| At any rate, as Alan pointed out, in the current design the driver
| moudles should be dlclosed after the plD_DEVICE_INFO_<dirver>
| variable is obtained.

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

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

Quoting "Alan W. Irwin" <ir...@be...>:

> On Fri, 7 Feb 2003, Rafael Laboissiere wrote:
> 
> > * Alan W. Irwin <ir...@be...> [2003-02-06 18:52]:
> >
> > > The most important point, however, is you do see segfaults on your
> machine
> > > so you have confirmed there is a severe problem, and you therefore have
> > > something that you can debug for your situation.
> > >
> > > Good luck in figuring this out!
> >
> > I think I found the source of the problem, see my last cvs commit.  Could
> > you guys confirm that HEAD works for you now?
> 
> Yes with a qualification.
> 
> No segfaults for ./x01c with the "Joao" configuration.

Try removing the tkwin driver from the install directory and uncommenting the 
lt_dlclose (dlhand) in plcore.c that Rafael last cvs commit has commented.
x01c now works for me. tkwin is a bad-boy!

Joao

PS-there is no need to remove the tkwin.* files, it's enough to

> mv tkwin.la tkwin.la-

To get the tkwin (not) working again is enough to

> mv tkwin.la- tkwin.la

as Rafael code only tries to load files that have a .la extension. 
That's the beauty of the scheme! (that should only be a bitmore robust.)

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

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

* Maurice LeBrun <mj...@ga...> [2003-02-09 21:13]:

> I've not been following the discussion very closely, but does this mean that
> the code currently loads all dynamic drivers at startup time?  If true, this
> seems against the spirit of dynamic drivers, and adds unnecessarily to the
> memory used by the application.

This is what I thought at the beginning and this is why I proposed the
alternative design with the <driver>.rc files.  However here is what Joao
wrote some days ago:

* João Cardoso <jc...@fe...> [2003-02-07 14:51]:

> Your concerns that dlopen() would load all libraries that a driver needs 
> does not apply, as this would only happens if some drivers code is 
> executed, which is not the case. As libtool's info says:
> 
>     "Unresolved symbols in the module are resolved using
>      its dependency libraries"
> 
> As the symbols you are looking for are in the modules, no further 
> loading will occur.

I hope that this is true for all architectures.

At any rate, as Alan pointed out, in the current design the driver moudles
should be dlclosed after the plD_DEVICE_INFO_<dirver> variable is obtained.

-- 
Rafael

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

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

On Sun, 9 Feb 2003, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > Summary: the new code loops over every device so will trigger the
>  > complete collection of valgrind errors for all devices (just xwin in this
>  > case) while the old code just looked at the user-specified device so gets no
>  > valgrind errors (except when the user specified xwin).
>
> I've not been following the discussion very closely, but does this mean that
> the code currently loads all dynamic drivers at startup time?  If true, this
> seems against the spirit of dynamic drivers, and adds unnecessarily to the
> memory used by the application.

Good question.....

Here is my understanding of our current situation. Rafael's code is designed
on startup to momentarily load each driver to collect and store required
information about it (as opposed to storing the required information in
drivers/drivers.db).  And Joao did some timing to show this loading of all
drivers was very fast. However, at the moment "momentarily" is until exit
from PLplot and consequently PLplot uses more memory then it should because
of a bug in libltdl that doesn't allow unloading.  But once that bug is fixed
it is only a matter of uncommenting one line in plcore.c to get a leaner,
meaner PLplot.

Alan

__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the Canadian Centre for Climate Modelling and
Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software
package (plplot.org).

__________________________

Linux-powered Science
__________________________

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

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

Alan W. Irwin writes:
 > Summary: the new code loops over every device so will trigger the
 > complete collection of valgrind errors for all devices (just xwin in this
 > case) while the old code just looked at the user-specified device so gets no
 > valgrind errors (except when the user specified xwin).

I've not been following the discussion very closely, but does this mean that
the code currently loads all dynamic drivers at startup time?  If true, this
seems against the spirit of dynamic drivers, and adds unnecessarily to the
memory used by the application.

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