PLplot

On Dec 28, 2003, at 4:11 PM, Alan W. Irwin wrote:

>> Yes, that works (tested with latest cvs release)!
>
> Excellent.

The python examples also work.


> Yes, fonts (and needed geographical map information for one of the 
> examples)
> is installed automatically  in $prefix/lib/plplot$version/data
>
> That translates to /usr/local/plplot_at/lib/plplot5.2.1/data in my case
> because I am using --prefix=/usr/local/plplot_at, and the fonts (and 
> maps)
> are found without difficulty for this unique prefix (and should be for 
> any
> other configuration prefix).
>
> I suspect what is going on is your fink install is using a staging area
> (similar to what goes on with both rpm and deb builds before the binary
> package is formed).  In the rpm case, we use a ./configure prefix
> corresponding to the final install area (./configure --prefix=/usr in 
> that
> case, and ./configure --prefix=/sw in the fink case), and we install 
> in the
> staging area using the following command:
>
> make DESTDIR=/staging_area install
>
> where /staging_area is the absolute path of the staging area
> where fink temporarily installs before putting its final binary package
> together.


I think I figured out what is going on. For the fink package I moved 
all the data and examples from /sw/lib/plplot/ to /sw/share/plplot, 
which is where the fink docs recommend to put architecture independent 
stuff. Apparently the examples expect the fonts to be in /sw/lib/plplot 
which is why I get the error. If I leave everything in /sw/lib/plplot, 
the examples work fine. So I will leave the examples, etc in /sw/lib, 
unless there is a way I can fix the font path rather easily, maybe by 
applying a patch?

- Koen.

* Koen van der Drift <kvddrift@...> [2003-12-29 09:04]:

> I think I figured out what is going on. For the fink package I moved 
> all the data and examples from /sw/lib/plplot/ to /sw/share/plplot, 
> which is where the fink docs recommend to put architecture independent 
> stuff. Apparently the examples expect the fonts to be in /sw/lib/plplot 
> which is why I get the error. If I leave everything in /sw/lib/plplot, 
> the examples work fine. So I will leave the examples, etc in /sw/lib, 
> unless there is a way I can fix the font path rather easily, maybe by 
> applying a patch?

You can override the path for the data files with the DATA_DIR environment
variable.  Using bash, you can do this, for instance:

    DATA_DIR=share/plplot/data ./configure

and the data files will land on $prefix/share/plplot/data.

The problem with this approach is that the driver modules (which *_are_*
architecture-dependent) will be installed in $prefix/share/plplot/driversd.
One way to overcome this is by doing (okay, that's tricky, but you asked for
it; and, hey, no patches needed!):

    DATA_DIR=share/plplot/data DRV_DIR=../../../lib/plplot/drivers ./configure

Notice the "../../.." needed in the definition of the environment variable
DRV_DIR.  This is because the core code of the PLplot library composes the
drivers directory like this (in src/plcore.c):

    drvdir = DATA_DIR "/" DRV_DIR;

However, this may be a non-issue for Fink right now, because dynamical
loading of driver modules does not work on Mac OS X (yet).

An unrelated question, just out of curiosity: my knowledge of Fink is almost
zero, but I know it is dpkg-based.  How much from my Debian packaging work
are you using in order to build the Fink PLplot package?

-- 
Rafael

On 2003-12-29 09:04-0500 Koen van der Drift wrote:

> I think I figured out what is going on. For the fink package I moved
> all the data and examples from /sw/lib/plplot/ to /sw/share/plplot,
> which is where the fink docs recommend to put architecture independent
> stuff. Apparently the examples expect the fonts to be in /sw/lib/plplot
> which is why I get the error. If I leave everything in /sw/lib/plplot,
> the examples work fine. So I will leave the examples, etc in /sw/lib,
> unless there is a way I can fix the font path rather easily, maybe by
> applying a patch?

Actually fink's recommendations might be a wakeup call that we should
consider moving fonts (and maps) to $prefix/share/plplot location for the
PLplot package as a whole.  Does this make more sense under the FHS
(http://www.pathname.com/fhs/)?  I haven't formed an opinion yet (no time to
look into it), but I would appreciate someone investigating this issue.
Usually, Debian gets FHS issues right in their packaging policy.  What do
you do with the fonts and maps, Rafael, for your debian packaging of PLplot?

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

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

Programming affiliations with the PLplot scientific plotting software
package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the
Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

* Alan W. Irwin <airwin@...> [2003-12-29 09:32]:

> Actually fink's recommendations might be a wakeup call that we should
> consider moving fonts (and maps) to $prefix/share/plplot location for the
> PLplot package as a whole.  Does this make more sense under the FHS
> (http://www.pathname.com/fhs/)?

Yes, absolutely.  Font and map files are architecture-independent, as far as
I know, and must be put under $prefix/share.

> I haven't formed an opinion yet (no time to look into it), but I would
> appreciate someone investigating this issue. Usually, Debian gets FHS
> issues right in their packaging policy.

It depends on how meticulous the package maintainer is... :-)

> What do you do with the fonts and maps, Rafael, for your debian packaging
> of PLplot?

I have not been meticulous enough on this issue.  Of course, I should
implement the same solution that I suggested to Keon for my Debian packages.
Even better than that, we should change it directly in the upstream source.
We have now in configure.ac:

    DATA_DIR="lib/${PACKAGE}${VERSION}/data"
    DRV_DIR="../drivers$LIB_TAG"
    
I suggest to change it to:

    DATA_DIR="share/${PACKAGE}${VERSION}/data"
    DRV_DIR="../../../lib/${PACKAGE}${VERSION}/drivers$LIB_TAG"

The stupid dot-slashes "../../.." are needed because of the code in
plcore.c.  Getting rid of them may mean a certain amount of work.

Should I change configure.ac as above?

-- 
Rafael

Hi all,

I have been able to do some more testing, and I now also have the 
tcl/tk scripting and examples working, although I get the following 
warning when making the examples:


[ModusOperandi:plplot5.2.1.cvs.20031228/examples/c] koen% sudo make
plplot_libtool --mode=link gcc -g -O2 x01c.c -I/sw/include/plplot 
-L/sw/lib -lplplotd -o x01c
mkdir .libs
gcc -g -O2 x01c.c -I/sw/include/plplot -o x01c  -L/sw/lib 
/sw/lib/libplplotd.dylib /sw/lib/libcsirocsa.dylib -ltk -ltcl 
-L/usr/X11R6/lib -lX11 -lm
ld: warning multiple definitions of symbol _tclPlatStubsPtr
/sw/lib/libtcl.dylib(tclStubLib.o) definition of _tclPlatStubsPtr
/sw/lib/libtk.dylib(tclStubLib.o) definition of _tclPlatStubsPtr
ld: warning multiple definitions of symbol _tclIntStubsPtr
/sw/lib/libtcl.dylib(tclStubLib.o) definition of _tclIntStubsPtr
/sw/lib/libtk.dylib(tclStubLib.o) definition of _tclIntStubsPtr
ld: warning multiple definitions of symbol _Tcl_InitStubs
/sw/lib/libtcl.dylib(tclStubLib.o) definition of _Tcl_InitStubs
/sw/lib/libtk.dylib(tclStubLib.o) definition of _Tcl_InitStubs
ld: warning multiple definitions of symbol _tclIntPlatStubsPtr
/sw/lib/libtcl.dylib(tclStubLib.o) definition of _tclIntPlatStubsPtr
/sw/lib/libtk.dylib(tclStubLib.o) definition of _tclIntPlatStubsPtr
ld: warning multiple definitions of symbol _tclStubsPtr
/sw/lib/libtcl.dylib(tclStubLib.o) definition of _tclStubsPtr
/sw/lib/libtk.dylib(tclStubLib.o) definition of _tclStubsPtr
ld: warning suggest use of -bind_at_load, as lazy binding may result in 
errors or different symbols being used
symbol _Tcl_InitStubs used from dynamic library 
/sw/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library 
/sw/lib/libtk8.4.dylib(tclStubLib.o)
symbol _tclIntPlatStubsPtr used from dynamic library 
/sw/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library 
/sw/lib/libtk8.4.dylib(tclStubLib.o)
symbol _tclIntStubsPtr used from dynamic library 
/sw/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library 
/sw/lib/libtk8.4.dylib(tclStubLib.o)
symbol _tclPlatStubsPtr used from dynamic library 
/sw/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library 
/sw/lib/libtk8.4.dylib(tclStubLib.o)
symbol _tclStubsPtr used from dynamic library 
/sw/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library 
/sw/lib/libtk8.4.dylib(tclStubLib.o)
symbol _TclSetStartupScriptFileName used from dynamic library 
/sw/lib/libtcl.dylib(tclMain.o) not from earlier dynamic library 
/sw/lib/libplplotd.9.dylib(tclMain.o)
symbol _TclGetStartupScriptFileName used from dynamic library 
/sw/lib/libtcl.dylib(tclMain.o) not from earlier dynamic library 
/sw/lib/libplplotd.9.dylib(tclMain.o)

Are these harmless?


Also, to enable output in png and jpeg, I installed the necessary 
packahes from fink, and as
seen below, lgd, lpng, ljpeg and lz are all found:

...
configure: WARNING: Java Native Interface include file not found,
configure: WARNING: setting enable_java=no
checking for GD header files... found in default
checking for main in -lgd... yes
checking for main in -lpng... yes
checking for main in -ljpeg... yes
checking for main in -lz... yes
checking for png support in libgd... no
configure: WARNING: png driver disabled
checking for jpeg support in libgd... no
configure: WARNING: jpeg driver disabled
checking for libcd header files... not found
configure: WARNING: libcd header files not found, setting enable_cgm=no
checking for main in -lcd... no
configure: WARNING: cd library not found, setting enable_cgm=no
checking for freetype library header files... not found
configure: WARNING: freetype header files not found,
configure: WARNING: setting with_freetype=no
checking for main in -lfreetype... no
configure: WARNING: freetype library not found, setting with_freetype=no
...

As you can see there is a problem with libgd, so enable_png and 
enable_jpeg are set to no. What version of the gd package are you 
using, maybe fink has a wrong version?

The other error is about the freetype files, which cannot be found. I 
have XWindows installed, and know that other packages are able to use 
the freetype files.

If freetype support is important to plplot, is there a way I can fix 
this?





thanks,

- Koen.

On 2003-12-29 21:07+0100 Rafael Laboissiere wrote:

> Even better than that, we should change it directly in the upstream source.
> We have now in configure.ac:
>
>     DATA_DIR="lib/${PACKAGE}${VERSION}/data"
>     DRV_DIR="../drivers$LIB_TAG"
>
> I suggest to change it to:
>
>     DATA_DIR="share/${PACKAGE}${VERSION}/data"
>     DRV_DIR="../../../lib/${PACKAGE}${VERSION}/drivers$LIB_TAG"
>
> The stupid dot-slashes "../../.." are needed because of the code in
> plcore.c.  Getting rid of them may mean a certain amount of work.
>
> Should I change configure.ac as above?

Fine with me.

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

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

Programming affiliations with the PLplot scientific plotting software
package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the
Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

* Alan W. Irwin <airwin@...> [2003-12-29 13:40]:

> On 2003-12-29 21:07+0100 Rafael Laboissiere wrote:
> 
> > Even better than that, we should change it directly in the upstream source.
> > We have now in configure.ac:
> >
> >     DATA_DIR="lib/${PACKAGE}${VERSION}/data"
> >     DRV_DIR="../drivers$LIB_TAG"
> >
> > I suggest to change it to:
> >
> >     DATA_DIR="share/${PACKAGE}${VERSION}/data"
> >     DRV_DIR="../../../lib/${PACKAGE}${VERSION}/drivers$LIB_TAG"
> >
> > The stupid dot-slashes "../../.." are needed because of the code in
> > plcore.c.  Getting rid of them may mean a certain amount of work.
> >
> > Should I change configure.ac as above?
> 
> Fine with me.

I will wait for the other developers' reactions before doing the change.

Just a thought that came to my mind: why don't we have options
--with-data-dir and --with-drv-dir to configure?

-- 
Rafael

On 2003-12-29 15:52-0500 Koen van der Drift wrote:

> Hi all,
>
> I have been able to do some more testing, and I now also have the
> tcl/tk scripting and examples working, although I get the following
> warning when making the examples:
>
>
> [ModusOperandi:plplot5.2.1.cvs.20031228/examples/c] koen% sudo make
> plplot_libtool --mode=link gcc -g -O2 x01c.c -I/sw/include/plplot
> -L/sw/lib -lplplotd -o x01c
> mkdir .libs
> gcc -g -O2 x01c.c -I/sw/include/plplot -o x01c  -L/sw/lib
> /sw/lib/libplplotd.dylib /sw/lib/libcsirocsa.dylib -ltk -ltcl
> -L/usr/X11R6/lib -lX11 -lm
> ld: warning multiple definitions of symbol _tclPlatStubsPtr
> /sw/lib/libtcl.dylib(tclStubLib.o) definition of _tclPlatStubsPtr
> /sw/lib/libtk.dylib(tclStubLib.o) definition of _tclPlatStubsPtr
> ld: warning multiple definitions of symbol _tclIntStubsPtr
> /sw/lib/libtcl.dylib(tclStubLib.o) definition of _tclIntStubsPtr
> /sw/lib/libtk.dylib(tclStubLib.o) definition of _tclIntStubsPtr
> ld: warning multiple definitions of symbol _Tcl_InitStubs
> /sw/lib/libtcl.dylib(tclStubLib.o) definition of _Tcl_InitStubs
> /sw/lib/libtk.dylib(tclStubLib.o) definition of _Tcl_InitStubs
> ld: warning multiple definitions of symbol _tclIntPlatStubsPtr
> /sw/lib/libtcl.dylib(tclStubLib.o) definition of _tclIntPlatStubsPtr
> /sw/lib/libtk.dylib(tclStubLib.o) definition of _tclIntPlatStubsPtr
> ld: warning multiple definitions of symbol _tclStubsPtr
> /sw/lib/libtcl.dylib(tclStubLib.o) definition of _tclStubsPtr
> /sw/lib/libtk.dylib(tclStubLib.o) definition of _tclStubsPtr
> ld: warning suggest use of -bind_at_load, as lazy binding may result in
> errors or different symbols being used
> symbol _Tcl_InitStubs used from dynamic library
> /sw/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library
> /sw/lib/libtk8.4.dylib(tclStubLib.o)
> symbol _tclIntPlatStubsPtr used from dynamic library
> /sw/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library
> /sw/lib/libtk8.4.dylib(tclStubLib.o)
> symbol _tclIntStubsPtr used from dynamic library
> /sw/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library
> /sw/lib/libtk8.4.dylib(tclStubLib.o)
> symbol _tclPlatStubsPtr used from dynamic library
> /sw/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library
> /sw/lib/libtk8.4.dylib(tclStubLib.o)
> symbol _tclStubsPtr used from dynamic library
> /sw/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library
> /sw/lib/libtk8.4.dylib(tclStubLib.o)
> symbol _TclSetStartupScriptFileName used from dynamic library
> /sw/lib/libtcl.dylib(tclMain.o) not from earlier dynamic library
> /sw/lib/libplplotd.9.dylib(tclMain.o)
> symbol _TclGetStartupScriptFileName used from dynamic library
> /sw/lib/libtcl.dylib(tclMain.o) not from earlier dynamic library
> /sw/lib/libplplotd.9.dylib(tclMain.o)
>
> Are these harmless?

Possibly, although it looks like there are some general nameclash issues
(same symbols defined in both libraries) that need to be sorted out for the
tcl and tk libraries in Mac OS X.

To make sure these issues are harmless, I suggest doing the following
tcl/tk tests for PLplot:

Try

./x01c -dev tk

Does that interactive device (that depends on tcl/tk) work?

Also in the _installed_ examples directory (or copy of it) try the
./plplot-test.sh script.  That is a comprehensive check that all the
language interfaces (including tcl) are working properly for file devices.
Lots of different plots (postscript by default, but try ./plplot-test.sh
--help to see about other file device alternatives) are produced so don't
give up on this command if not many messages are being printed as it
executes.

Also try some of the interactive checks of tcl/tk mentioned in
examples/tcl/README.tcldemos and examples/tk/README.tkdemos.

>
>
> Also, to enable output in png and jpeg, I installed the necessary
> packahes from fink, and as
> seen below, lgd, lpng, ljpeg and lz are all found:
>
> ...
> configure: WARNING: Java Native Interface include file not found,
> configure: WARNING: setting enable_java=no
> checking for GD header files... found in default
> checking for main in -lgd... yes
> checking for main in -lpng... yes
> checking for main in -ljpeg... yes
> checking for main in -lz... yes
> checking for png support in libgd... no
> configure: WARNING: png driver disabled
> checking for jpeg support in libgd... no
> configure: WARNING: jpeg driver disabled
> checking for libcd header files... not found
> configure: WARNING: libcd header files not found, setting enable_cgm=no
> checking for main in -lcd... no
> configure: WARNING: cd library not found, setting enable_cgm=no
> checking for freetype library header files... not found
> configure: WARNING: freetype header files not found,
> configure: WARNING: setting with_freetype=no
> checking for main in -lfreetype... no
> configure: WARNING: freetype library not found, setting with_freetype=no
> ...
>
> As you can see there is a problem with libgd, so enable_png and
> enable_jpeg are set to no. What version of the gd package are you
> using, maybe fink has a wrong version?

The above message means
every required gd header, and png, jpeg, and zlib library was found, but
this section of sysloc.in did not work correctly:

    AC_MSG_CHECKING(for png support in libgd)
    AC_TRY_LINK_FUNC([
      gdImagePng
    ], [AC_MSG_RESULT(yes)], [
      AC_MSG_RESULT(no)
      AC_MSG_WARN(png driver disabled)
      enable_png=no
    ])

This fails if you have a really old version of libgd (like for RH 6.2), but
I doubt that is the source of the problem. For example, version 2.0.1 of
libgd works fine on Debian stable, and IIRC even libgd 1.8.x worked well.

What does the relevant part of your config.log say about this test?  Mine
reads:

configure:22002: checking for png support in libgd
configure:22031: gcc -o conftest -Idefault   conftest.c -Ldefault -Ldefault -Ldefault -Ldefault -lgd -lpng -ljpeg -lz >&5
configure:22037: $? = 0
configure:22041: test -z
                         || test ! -s conftest.err
configure:22044: $? = 0
configure:22047: test -s conftest
configure:22050: $? = 0
configure:22052: result: yes

>
> The other error is about the freetype files, which cannot be found. I
> have XWindows installed, and know that other packages are able to use
> the freetype files.
>
> If freetype support is important to plplot, is there a way I can fix
> this?

freetype is a way to use system fonts in PLplot rather than the default
built-in (Hershey) fonts.  It's a fairly new feature that currently is only
implemented for the gd-associated devices (png, jpeg).  See
http://plplot.sourceforge.net/resources/docbook-manual/plplot-html-5.2.1.cvs.20030929/freetype-notes.html
for more discussion. Although our current support for feature is limited to
these two devices, nevertheless it is a fairly interesting feature that is
well worth including.

From sysloc.in, currently the freetype headers are only looked for
in /usr/include/freetype2 and /usr/local/include/freetype2, and similarly
the freetype library is only looked for in /usr/lib and /usr/local/lib.
To specify other locations set the FREETYPEINCDIR and/or FREETYPELIBDIR
environment variables before running the ./configure command.

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

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

Programming affiliations with the PLplot scientific plotting software
package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the
Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

On Mon, 29 Dec 2003, Rafael Laboissiere wrote:

> * Alan W. Irwin <airwin@...> [2003-12-29 13:40]:
> 
> > On 2003-12-29 21:07+0100 Rafael Laboissiere wrote:
> > 
> > > Even better than that, we should change it directly in the upstream source.
> > > We have now in configure.ac:
> > >
> > >     DATA_DIR="lib/${PACKAGE}${VERSION}/data"
> > >     DRV_DIR="../drivers$LIB_TAG"
> > >
> > > I suggest to change it to:
> > >
> > >     DATA_DIR="share/${PACKAGE}${VERSION}/data"
> > >     DRV_DIR="../../../lib/${PACKAGE}${VERSION}/drivers$LIB_TAG"
> > >
> > > The stupid dot-slashes "../../.." are needed because of the code in
> > > plcore.c.  Getting rid of them may mean a certain amount of work.
> > >
> > > Should I change configure.ac as above?
> > 
> > Fine with me.
> 
> I will wait for the other developers' reactions before doing the change.
> 
> Just a thought that came to my mind: why don't we have options
> --with-data-dir and --with-drv-dir to configure?
> 

This might be a bit confusing, since configure already has 
--datadir=DIR          read-only architecture-independent data [PREFIX/share]

In the end don't you want something like 
DATA_DIR="${datadir}/${PACKAGE}${VERSION}/data"
or even leave off the last "data" as superfluous?
This way the user or packager can just specify --datadir
if needed.

Brian

-- 
======================================================================
Brian D. Wright                                 Tel: (415)476-1007   
Dept. of Physiology, Box 0444		      	Fax: (415)476-4929    
Keck Center for Integrative Neuroscience      	bdwright@... 
University of California, San Francisco	      
513 Parnassus Avenue
San Francisco, CA 94143-0444
======================================================================

* Brian D. Wright <bdwright@...> [2003-12-29 15:51]:

> On Mon, 29 Dec 2003, Rafael Laboissiere wrote:
>
> > Just a thought that came to my mind: why don't we have options
> > --with-data-dir and --with-drv-dir to configure?
> 
> This might be a bit confusing, since configure already has 
> --datadir=DIR          read-only architecture-independent data [PREFIX/share]
> 
> In the end don't you want something like 
> DATA_DIR="${datadir}/${PACKAGE}${VERSION}/data" or even leave off the last
> "data" as superfluous? This way the user or packager can just specify
> --datadir if needed.

Yes, we should definitively start using --datadir and --libdir for,
respectively, the font/map files and the driver modules directories.  Also,
the code in plcore.c must be changed, because DRV_DIR is currently specified
relatively to DATA_DIR (this is ugly, counter intuitive, and may be non
FHS-compliant).

-- 
Rafael

* Rafael Laboissiere <rlaboiss@...> [2003-12-29 23:29]:

> * Alan W. Irwin <airwin@...> [2003-12-29 13:40]:
> 
> > On 2003-12-29 21:07+0100 Rafael Laboissiere wrote:
> > 
> > > I suggest to change it to:
> > >
> > >     DATA_DIR="share/${PACKAGE}${VERSION}/data"
> > >     DRV_DIR="../../../lib/${PACKAGE}${VERSION}/drivers$LIB_TAG"
> > >
> > > Should I change configure.ac as above?
> > 
> > Fine with me.
> 
> I will wait for the other developers' reactions before doing the change.

Discussing privately with Alan, I realized that the changes were not that
dramatic and I went ahead.

I just did a big cvs commit that concerned more than 20 files.  See the
commit message for details.  I probably broke things, although I could build
the Debian packages and run some examples without errors.  Those with access
to CVS HEAD (and with a working head on the shoulders :-) please, check my
changes.

I will probably soon review the situation of other *DIR variables (like
TCL_DIR and DOCDIR).

-- 
Rafael

On Dec 29, 2003, at 5:59 PM, Alan W. Irwin wrote:

> To make sure these issues are harmless, I suggest doing the following
> tcl/tk tests for PLplot:
>
> Try
>
> ./x01c -dev tk
>
> Does that interactive device (that depends on tcl/tk) work?

No, I get this error:

plFindCommand: cannot locate command: plserver
bin dir="/sw/bin"

*** PLPLOT ERROR ***
Unable to fork server process
Program aborted

/sw/bin/plserver does exist, though.


I get this error from the Mac OS X terminal's command line or from 
within an X window.



> Also in the _installed_ examples directory (or copy of it) try the
> ./plplot-test.sh script.

That works, and results in plgrid.ps, plot.ps, pythondemos.ps, 
tcldemos.ps, and the files for c and cc and cxx.
I haven't had time to look at the other tests you suggested.


> This fails if you have a really old version of libgd (like for RH 
> 6.2), but
> I doubt that is the source of the problem. For example, version 2.0.1 
> of
> libgd works fine on Debian stable, and IIRC even libgd 1.8.x worked 
> well.

I have gd 2.0.12 through fink.

> What does the relevant part of your config.log say about this test?  
> Mine
> reads:
>
> configure:22002: checking for png support in libgd
> configure:22031: gcc -o conftest -Idefault   conftest.c -Ldefault 
> -Ldefault -Ldefault -Ldefault -lgd -lpng -ljpeg -lz >&5
> configure:22037: $? = 0
> configure:22041: test -z
>                          || test ! -s conftest.err
> configure:22044: $? = 0
> configure:22047: test -s conftest
> configure:22050: $? = 0
> configure:22052: result: yes
>


This is in config.log:

configure:22267: checking for png support in libgd
configure:22296: gcc -o conftest -Idefault   conftest.c -./sw/include 
conftest.c -Ldefault -Ldefault -Ldefault -Ldefault -lgd -lpng -ljpeg 
-lz >&5
ld: warning -L: directory name (default) does not exist
ld: warning -L: directory name (default) does not exist
ld: warning -L: directory name (default) does not exist
ld: warning -L: directory name (default) does not exist
ld: can't locate file for: -lgd


- Koen.

* Koen van der Drift <kvddrift@...> [2003-12-30 19:22]:

> On Dec 29, 2003, at 5:59 PM, Alan W. Irwin wrote:
> 
> >What does the relevant part of your config.log say about this test?  
> >Mine
> >reads:
> >
> >configure:22002: checking for png support in libgd
> >configure:22031: gcc -o conftest -Idefault   conftest.c -Ldefault 
> >-Ldefault -Ldefault -Ldefault -lgd -lpng -ljpeg -lz >&5
> >configure:22037: $? = 0
> >configure:22041: test -z
> >                         || test ! -s conftest.err
> >configure:22044: $? = 0
> >configure:22047: test -s conftest
> >configure:22050: $? = 0
> >configure:22052: result: yes
> >
> 
> 
> This is in config.log:
> 
> configure:22267: checking for png support in libgd
> configure:22296: gcc -o conftest -Idefault   conftest.c -./sw/include 
> conftest.c -Ldefault -Ldefault -Ldefault -Ldefault -lgd -lpng -ljpeg 
> -lz >&5
> ld: warning -L: directory name (default) does not exist
> ld: warning -L: directory name (default) does not exist
> ld: warning -L: directory name (default) does not exist
> ld: warning -L: directory name (default) does not exist
> ld: can't locate file for: -lgd

I see something really weird in both Alan's and Koen's config.log.  Those
"-Idefault" and "-Ldefault" should *_never_* appear there.  Alan, I think
that you wrote that section of GD library checks in configure.ac.  Haven't
you forgot a call to ADD_TO_LIBS there?

-- 
Rafael

* Rafael Laboissiere <rlaboiss@...> [2003-12-31 01:46]:

> I see something really weird in both Alan's and Koen's config.log.  Those
> "-Idefault" and "-Ldefault" should *_never_* appear there.  Alan, I think
> that you wrote that section of GD library checks in configure.ac.

I meant sysloc.in, sorry.
 
-- 
Rafael

On 2003-12-31 01:46+0100 Rafael Laboissiere wrote:

> I see something really weird in both Alan's and Koen's config.log.  Those
> "-Idefault" and "-Ldefault" should *_never_* appear there.  Alan, I think
> that you wrote that section of GD library checks in configure.ac.  Haven't
> you forgot a call to ADD_TO_LIBS there?

Thanks for spotting that.  I agree that is weird and should not happen.
However, I don't think ADD_TO_LIBS (and ADD_TO_INCS) is necessary because
of the "default" logic that occurs in configure.ac.  But somehow that
logic, e.g.,

   GDLIBCMD=
   if test "$GDLIBDIR" != default; then
         GDLIBCMD="$GDLIBCMD -L$GDLIBDIR"
   fi

is failing.  Should default be quoted? It appears elsewhere in configure.ac
that tests are sometimes done with the quotes on the second argument and
sometimes not. (I hate these m4 parsing issues).

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

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

Programming affiliations with the PLplot scientific plotting software
package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the
Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

On 2003-12-30 19:22-0500 Koen van der Drift wrote:

> On Dec 29, 2003, at 5:59 PM, Alan W. Irwin wrote:
>
> > To make sure these issues are harmless, I suggest doing the following
> > tcl/tk tests for PLplot:
> >
> > Try
> >
> > ./x01c -dev tk
> >
> > Does that interactive device (that depends on tcl/tk) work?
>
> No, I get this error:
>
> plFindCommand: cannot locate command: plserver
> bin dir="/sw/bin"
>
> *** PLPLOT ERROR ***
> Unable to fork server process
> Program aborted
>
> /sw/bin/plserver does exist, though.

What is the result of "which plserver".

If that command finds plserver okay, then I believe the above issue is a
showstopper for the tcl/tk interface to PLplot on Mac OS X. In fact, we
struggled with finding tcl/tk stuff we needed for PLplot on Linux until we
got a kludge that shakily worked for that situation for -dev tk.  What is
really needed is to have some decent tcl/tk autotools macros to help PLplot
find the tcl/tk stuff it needs.  But I don't know of any that are compatible
with the latest autotools so Mac OS X users may just have to wait to get
access to -dev tk until that situation is rectified.

>
>
> I get this error from the Mac OS X terminal's command line or from
> within an X window.
>
>
>
> > Also in the _installed_ examples directory (or copy of it) try the
> > ./plplot-test.sh script.
>
> That works, and results in plgrid.ps, plot.ps, pythondemos.ps,
> tcldemos.ps, and the files for c and cc and cxx.

Good, that is a pretty comprehensive test of the non-interactive file
devices. Please remind us of the plplot version, the version of Mac OS X and
the configure options you used for this success story.  (There have been a
lot of different Mac OS X threads recently.)

From Rafael's post we probably know the "default" reason for your libgd
problems that you also discussed in your post, and hopefully we will have a
fix soon.

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

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

Programming affiliations with the PLplot scientific plotting software
package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the
Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

On Dec 30, 2003, at 9:26 PM, Alan W. Irwin wrote:

>> No, I get this error:
>>
>> plFindCommand: cannot locate command: plserver
>> bin dir="/sw/bin"
>>
>> *** PLPLOT ERROR ***
>> Unable to fork server process
>> Program aborted
>>
>> /sw/bin/plserver does exist, though.
>
> What is the result of "which plserver".

/sw/bin/plserver

> But I don't know of any that are compatible
> with the latest autotools so Mac OS X users may just have to wait to 
> get
> access to -dev tk until that situation is rectified.

I have absolutely no experiece with tcltk, so cannot help here :(

>> That works, and results in plgrid.ps, plot.ps, pythondemos.ps,
>> tcldemos.ps, and the files for c and cc and cxx.
>
> Good, that is a pretty comprehensive test of the non-interactive file
> devices. Please remind us of the plplot version, the version of Mac OS 
> X and
> the configure options you used for this success story.  (There have 
> been a
> lot of different Mac OS X threads recently.)

This is on Mac OS X 10.3.2 and plplot-cvs-20031228


>
> From Rafael's post we probably know the "default" reason for your libgd
> problems that you also discussed in your post, and hopefully we will 
> have a
> fix soon.


Thanks again for all the help. It looks like the plplot fink package is 
shaping up and I will submit it to the fink project when the 5.2.2 
release is out. Only scripting for octave and Fortran are not added yet 
- are these used by many users?


- Koen.

On 2003-12-30 21:58-0500 Koen van der Drift wrote:

> On Dec 30, 2003, at 9:26 PM, Alan W. Irwin wrote:
> > Good, that is a pretty comprehensive test of the non-interactive file
> > devices. Please remind us of the plplot version, the version of Mac OS
> > X and
> > the configure options you used for this success story.  (There have
> > been a
> > lot of different Mac OS X threads recently.)
>
> This is on Mac OS X 10.3.2 and plplot-cvs-20031228

What were the configure options (other than prefix)?

>
> Thanks again for all the help. It looks like the plplot fink package is
> shaping up and I will submit it to the fink project when the 5.2.2
> release is out. Only scripting for octave and Fortran are not added yet
> - are these used by many users?

Both the fortran and octave language interfaces are well worth having.

For example, fortran dates back to 1954, and because it is such a simple,
efficient language it is still the workhorse for many scientific numerical
computations. However, the fortran interface to PLplot on Mac OS X is a sore
point which I have been working on with Michel Peyrard. I am very close to
the conclusion that the latest fink g77 (fortran compiler) is basically
incompatible with the latest Apple gcc version (see discussion at
http://www.chemistry.ucsc.edu/~wgscott/xtal/page2.html).  I am hoping Michel
(or you?) can find a g77 and gcc combination that are compatible (i.e., have
the same version numbers) that I can recommend to our Mac OS X users.  But
if not, then we will just have to wait until fink gets its g77 packaging
problem straightened out.

Also, there are questions about the current fortran configuration even on
Linux. If you do decide to try some fortran tests, please wait until Rafael
and I sort out whether to use AC_F77_LIBRARY_LDFLAGS or not.

I don't know anything about the fink packaging of octave (which is a free
mostly Matlab compatible, high-level language).  But if you have octave
(2.1.x is necessary to work with PLplot now) installed it is certainly worth
a try to see whether PLplot will work with it. (If octave is found on your
system it will be enabled by default and plplot-test.sh will test it for the
non-interactive case.)

Thanks very much for your work exploring all the PLplot possibilities on Mac
OS X and putting together a fink package for PLplot.

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

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

Programming affiliations with the PLplot scientific plotting software
package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the
Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Koen,

I was the one who posted a request for a fink package for plplot. I have
now a working version thanks to the cvs tarball (altough there are still
some problems) but I would definitely appreciate a fink package WITH
fortran, and I am probably not alone. Fortran is still heavily used in the
scientific community and the inteest of plplot is that it can display
results of simulations while they are running.

Michel


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Michel Peyrard, Professeur       % Ph: +33 (0)4 7272 8374            %
% Laboratoire de Physique          % Fax: +33 (0)4 7272 8080           %
% Ecole Normale Sup=E9rieure de Lyon % e-mail:Michel.Peyrard@... %
% 46 all=E9e d'Italie                % perso.ens-lyon.fr/michel.peyrard  %
% 69364 Lyon Cedex 07, France      % (GPG key available on home page)  %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

On Tue, 30 Dec 2003, Koen van der Drift wrote:

>
> On Dec 30, 2003, at 9:26 PM, Alan W. Irwin wrote:
>
> >> No, I get this error:
> >>
> >> plFindCommand: cannot locate command: plserver
> >> bin dir=3D"/sw/bin"
> >>
> >> *** PLPLOT ERROR ***
> >> Unable to fork server process
> >> Program aborted
> >>
> >> /sw/bin/plserver does exist, though.
> >
> > What is the result of "which plserver".
>
> /sw/bin/plserver
>
> > But I don't know of any that are compatible
> > with the latest autotools so Mac OS X users may just have to wait to
> > get
> > access to -dev tk until that situation is rectified.
>
> I have absolutely no experiece with tcltk, so cannot help here :(
>
> >> That works, and results in plgrid.ps, plot.ps, pythondemos.ps,
> >> tcldemos.ps, and the files for c and cc and cxx.
> >
> > Good, that is a pretty comprehensive test of the non-interactive file
> > devices. Please remind us of the plplot version, the version of Mac OS
> > X and
> > the configure options you used for this success story.  (There have
> > been a
> > lot of different Mac OS X threads recently.)
>
> This is on Mac OS X 10.3.2 and plplot-cvs-20031228
>
>
> >
> > From Rafael's post we probably know the "default" reason for your libgd
> > problems that you also discussed in your post, and hopefully we will
> > have a
> > fix soon.
>
>
> Thanks again for all the help. It looks like the plplot fink package is
> shaping up and I will submit it to the fink project when the 5.2.2
> release is out. Only scripting for octave and Fortran are not added yet
> - are these used by many users?
>
>
> - Koen.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

* Alan W. Irwin <airwin@...> [2003-12-30 18:06]:

> On 2003-12-31 01:46+0100 Rafael Laboissiere wrote:
> 
> > I see something really weird in both Alan's and Koen's config.log.  Those
> > "-Idefault" and "-Ldefault" should *_never_* appear there.  Alan, I think
> > that you wrote that section of GD library checks in configure.ac.  Haven't
> > you forgot a call to ADD_TO_LIBS there?
> 
> Thanks for spotting that.  I agree that is weird and should not happen.
> However, I don't think ADD_TO_LIBS (and ADD_TO_INCS) is necessary because
> of the "default" logic that occurs in configure.ac.  But somehow that
> logic, e.g.,
> 
>    GDLIBCMD=
>    if test "$GDLIBDIR" != default; then
>          GDLIBCMD="$GDLIBCMD -L$GDLIBDIR"
>    fi
> 
> is failing.  Should default be quoted? It appears elsewhere in configure.ac
> that tests are sometimes done with the quotes on the second argument and
> sometimes not. (I hate these m4 parsing issues).

Strictly speaking, quotes are only really necessary when we have a 
variables on one of the sides of the comparison (like the "$GDLIBDIR"
above). This prevents from the case where the variable is above or the
variable contain special shell character (like spaces and the like).
This has nothing to do with m4 parsing.

To answer your question, both `default' and `"default"' should give
*_exactly_* the same result under Bourne shell.

I still think that ADD_TO_LIBS should be called after the GD, PNG, and JPEG
checks, in the same way it is done for libcd, FreeType, and Gnome.  Indeed,
it is in this macro that the string "default" is coped with.

-- 
Rafael

* Koen van der Drift <kvddrift@...> [2003-12-30 21:58]:

> Only scripting for octave and Fortran are not added yet - are these used by
> many users?

Just to echo Alan's words: Octave is an almost complete Matlab clone, even
better in some aspects.  The only area where Octave is lagging behind Matlab
is exactly... graphics!  This is one of the main reasons I got involved with
PLplot.

You will find lots of information on Octave in:

    http://www.octave.org
    http://octave.sf.net    

-- 
Rafael

On Dec 30, 2003, at 11:50 PM, Alan W. Irwin wrote:

>

>> This is on Mac OS X 10.3.2 and plplot-cvs-20031228
>
> What were the configure options (other than prefix)?

--disable-dindrivers --with-double --disable-f77

>
>>
>> Thanks again for all the help. It looks like the plplot fink package 
>> is
>> shaping up and I will submit it to the fink project when the 5.2.2
>> release is out. Only scripting for octave and Fortran are not added 
>> yet
>> - are these used by many users?
>
> Both the fortran and octave language interfaces are well worth having.
>

I'll give it a shot next year and check the messages about fortran. 
Note that I have no experience and knowledge about both lnguages, so I 
cannot promise anything :).

Another reason I am hesitating is that both fink packages are *huge*, 
so for some who only wants to use plplot with eg C, it will be 
overkill.


- Koen.

* Koen van der Drift <kvddrift@...> [2003-12-31 06:12]:

> Another reason I am hesitating is that both fink packages are *huge*, 
> so for some who only wants to use plplot with eg C, it will be 
> overkill.

This is why I split the Debian packages:

    libplplot9
    libplplot-dev
    plplot9-driver-xwin
    plplot9-driver-gnome
    plplot-tcl
    plplot-tcl-dev
    plplot9-driver-gd
    python-plplot
    octave-plplot
    plplot-doc

For using the PLplot library with other programs (like PDL), users have just
to have the libplplot9 package installed (1.1 M of size).  For development
with C, libplplot-dev (756 K) must also be installed.  Of course, plplot-doc
(3.8 M) is handful when doing development.

Could you do something similar for Fink?

-- 
Rafael

On 2003-12-31 06:12-0500 Koen van der Drift wrote:

>
> On Dec 30, 2003, at 11:50 PM, Alan W. Irwin wrote:
>
> >
>
> >> This is on Mac OS X 10.3.2 and plplot-cvs-20031228
> >
> > What were the configure options (other than prefix)?
>
> --disable-dindrivers --with-double --disable-f77

Thanks for that most useful report.  I am going to take this opportunity to
summarize the Mac OS X status.

* Please note that the combination of --disable-dyndrivers and --disable-f77
works.  In particular note the default shared libraries and python are
working.  (They did so in September with an older Mac OS X [10.1, I believe]
and older PLplot cvs snapshot, but this is the first confirmation for Mac OS
X 10.3 and a recent cvs snapshot.)

(Note the spelling correction on --disable-dyndrivers, and
also note that --with-double is default so you don't need to specify it.)

* Once the get-drv-info bug is fixed for Mac OS X, then you will also be
able to drop the --disable-dyndrivers limitation which will mean all Mac OS
X PLplot executables will be considerably smaller.

* The latest fink g77 3.4 fortran compiler is from the experimental
development line of gcc compilers and is thus extremely unlikely to be
compatible with gcc 3.3, the stable line of compilers from gcc including the
tweaked version of gcc 3.3 from Apple that is used for fink development. See
some discussion of this topic at
http://www.chemistry.ucsc.edu/~wgscott/xtal/page2.html where it is noted
that a lot of packages are now broken by the latest fink g77 "update" to
version 3.4.

* Also, apparently the recommended AC_F77_LIBRARY_LDFLAGS macro that we have
tried recently for PLplot configuration is incompatible with gcc 3.3. I
believe this is a bug in autoconf.

* Until these last two external issues get straightened out we cannot make
any forward progress in making the fortran interface to PLplot a smooth
experience on Mac OS X. Thus, I recommend using --disable-f77 for now.
However, if you want to try the fortran interface to PLplot on Mac OS X in
an experimental way, Michel has posted some workarounds for the problems
that currently occur.

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

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

Programming affiliations with the PLplot scientific plotting software
package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the
Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

On 2003-12-31 11:00+0100 Rafael Laboissiere wrote:

> * Alan W. Irwin <airwin@...> [2003-12-30 18:06]:
>
> > On 2003-12-31 01:46+0100 Rafael Laboissiere wrote:
> >
> > > I see something really weird in both Alan's and Koen's config.log.  Those
> > > "-Idefault" and "-Ldefault" should *_never_* appear there.  Alan, I think
> > > that you wrote that section of GD library checks in configure.ac.  Haven't
> > > you forgot a call to ADD_TO_LIBS there?
> >
> > Thanks for spotting that.  I agree that is weird and should not happen.
> > However, I don't think ADD_TO_LIBS (and ADD_TO_INCS) is necessary because
> > of the "default" logic that occurs in configure.ac.  But somehow that
> > logic, e.g.,
> >
> >    GDLIBCMD=
> >    if test "$GDLIBDIR" != default; then
> >          GDLIBCMD="$GDLIBCMD -L$GDLIBDIR"
> >    fi
> >
> > is failing.  Should default be quoted? It appears elsewhere in configure.ac
> > that tests are sometimes done with the quotes on the second argument and
> > sometimes not. (I hate these m4 parsing issues).
>
> Strictly speaking, quotes are only really necessary when we have a
> variables on one of the sides of the comparison (like the "$GDLIBDIR"
> above). This prevents from the case where the variable is above or the
> variable contain special shell character (like spaces and the like).
> This has nothing to do with m4 parsing.
>
> To answer your question, both `default' and `"default"' should give
> *_exactly_* the same result under Bourne shell.

Thanks for that clarification.

>
> I still think that ADD_TO_LIBS should be called after the GD, PNG, and JPEG
> checks, in the same way it is done for libcd, FreeType, and Gnome.  Indeed,
> it is in this macro that the string "default" is coped with.

I just realized the above logic actually works fine.

grep CMD Makefile
CDINCCMD =
CDLIBCMD = -lcd
FREETYPEINCCMD = -I/usr/include/freetype2
FREETYPELIBCMD = -lfreetype
GDINCCMD =
GDLIBCMD =  -lgd -lpng -ljpeg -lz
ITCLINCCMD = -I/usr/include/tcl8.3/itcl-private/generic
ITCLLIBCMD = -litcl3.1
ITKLIBCMD = -litk3.1
JAVAINCCMD = -I/home/software/java/IBMJava2-14//include
-I/home/software/java/IBMJava2-14//include
TCLINCCMD = -I/usr/include/tcl8.3/tcl-private/generic
TCLLIBCMD = -ltcl8.3
TKINCCMD = -I/usr/include/tcl8.3/tk-private/generic  -I/usr/X11R6/include
TKLIBCMD = -ltk8.3

but the above logic occurs after sysloc.in so does not affect the sysloc.in
test that was producing the -Ldefault.

Thus, I will look into using ADD_TO_LIBS in sysloc.in as you suggested and
also look carefully at whether all the "default" logic boilerplate in
configure.ac is really required. That will be 3rd on my PLplot ToDo list
after finishing fortran examples 16-18 and companion fortran interface
changes and doing comprehensive testing of the recent *DIR changes and your
forthcoming changes for the configuration of the examples.

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

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

Programming affiliations with the PLplot scientific plotting software
package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the
Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

On Dec 31, 2003, at 7:23 AM, Rafael Laboissiere wrote:

> This is why I split the Debian packages:
>
>     libplplot9
>     libplplot-dev
>     plplot9-driver-xwin
>     plplot9-driver-gnome
>     plplot-tcl
>     plplot-tcl-dev
>     plplot9-driver-gd
>     python-plplot
>     octave-plplot
>     plplot-doc
>
> For using the PLplot library with other programs (like PDL), users 
> have just
> to have the libplplot9 package installed (1.1 M of size).  For 
> development
> with C, libplplot-dev (756 K) must also be installed.  Of course, 
> plplot-doc
> (3.8 M) is handful when doing development.
>
> Could you do something similar for Fink?
>

Yes - that should be possible.

- Koen.

On Dec 30, 2003, at 9:26 PM, Alan W. Irwin wrote:

>
> If that command finds plserver okay, then I believe the above issue is 
> a
> showstopper for the tcl/tk interface to PLplot on Mac OS X. In fact, we
> struggled with finding tcl/tk stuff we needed for PLplot on Linux 
> until we
> got a kludge that shakily worked for that situation for -dev tk.


This is probably a silly question, but maybe the command ./x01 -dev tk 
only works if issued from a tk window? If so, how do I get such a 
window in the first place?


- Koen.

On 2004-01-01 07:38-0500 Koen van der Drift wrote:

>
> On Dec 30, 2003, at 9:26 PM, Alan W. Irwin wrote:
>
> >
> > If that command finds plserver okay, then I believe the above issue is
> > a
> > showstopper for the tcl/tk interface to PLplot on Mac OS X. In fact, we
> > struggled with finding tcl/tk stuff we needed for PLplot on Linux
> > until we
> > got a kludge that shakily worked for that situation for -dev tk.
>
>
> This is probably a silly question, but maybe the command ./x01 -dev tk
> only works if issued from a tk window? If so, how do I get such a
> window in the first place?

No, it creates the necessary environment from the command line by calling
plserver to do the heavy lifting.

So this "device" is actually implemented in a quite complicated and
therefore fragile (as I mentioned) way, but the results are worth having
since they include all the power of what is available from plserver.  To
make this device available cross-platform in a robust way we are going to
need some high-quality tcl/tk macros for autoconf to help PLplot find tcl/tk
locations and capabilities that it needs.

As a test of tcl/tk you could also try the new tk device -dev ntk which you
also run from the command-line.  It might work because my understanding is
ntk device is implemented in a less complicated way than the tk device, but
OTOH the ntk device capabilities have not been developed yet to the same level
that is available with the tk device.

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

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

Programming affiliations with the PLplot scientific plotting software
package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the
Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

On Jan 1, 2004, at 11:56 AM, Alan W. Irwin wrote:

>
> As a test of tcl/tk you could also try the new tk device -dev ntk 
> which you
> also run from the command-line.  It might work because my 
> understanding is
> ntk device is implemented in a less complicated way than the tk 
> device, but
> OTOH the ntk device capabilities have not been developed yet to the 
> same level
> that is available with the tk device.
>
>

No, that didn't work either ('unable to initialize Tk').

Not sure if I mentioned it before, but the error for -dev tk is:

tk_init: this isn't a Tk application couldn't connect to display 
"unix:0:0"
TCL command "plclient_link_end" failed:
		invalid command name "plclient_link_end"




Could it be version related? I have 8.4.1 installed.


- Koen.

* Alan W. Irwin <airwin@...> [2003-12-31 12:59]:

> I just realized the above logic actually works fine.
> 
> grep CMD Makefile
> CDINCCMD =
> CDLIBCMD = -lcd
> FREETYPEINCCMD = -I/usr/include/freetype2
> FREETYPELIBCMD = -lfreetype
> GDINCCMD =
> GDLIBCMD =  -lgd -lpng -ljpeg -lz
> ITCLINCCMD = -I/usr/include/tcl8.3/itcl-private/generic
> ITCLLIBCMD = -litcl3.1
> ITKLIBCMD = -litk3.1
> JAVAINCCMD = -I/home/software/java/IBMJava2-14//include
> -I/home/software/java/IBMJava2-14//include
> TCLINCCMD = -I/usr/include/tcl8.3/tcl-private/generic
> TCLLIBCMD = -ltcl8.3
> TKINCCMD = -I/usr/include/tcl8.3/tk-private/generic  -I/usr/X11R6/include
> TKLIBCMD = -ltk8.3
> 
> but the above logic occurs after sysloc.in so does not affect the sysloc.in
> test that was producing the -Ldefault.

But the library checks are done in sysloc.in and there is where the
"-Ldefault" appears.  This may be the source of the -lgd problem detected by
Keon.  

At any rate, I think that the autoconf code in sysloc.in for library
detection (gd, jpeg, zlib, etc) is highly non-standard and quite abstruse.
It was generated by cut & paste editing instead of using autoconf macros to
do the job.  This makes the code pretty unmaintainable.

I know, I know, the code works fine almost all the time, but I will see if I
can improve the situation in the future.

-- 
Rafael

On Jan 1, 2004, at 3:54 PM, Alan W. Irwin wrote:

> Of course
> it is possible such tools don't exist, but then I wonder how this 
> problem is
> handled by other projects with tcl/tk interfaces to C libraries?

Do you know any such projects? I can then see if they are available for 
fink / Mac OS X and maybe try to figure out how it was solved.

- Koen.

On Thursday 01 January 2004 17:11, Koen van der Drift wrote:
|  On Jan 1, 2004, at 11:56 AM, Alan W. Irwin wrote:
|  > As a test of tcl/tk you could also try the new tk device -dev ntk
|  > which you
|  > also run from the command-line.  It might work because my
|  > understanding is
|  > ntk device is implemented in a less complicated way than the tk
|  > device, but
|  > OTOH the ntk device capabilities have not been developed yet to the
|  > same level
|  > that is available with the tk device.
|
|  No, that didn't work either ('unable to initialize Tk').
|
|  Not sure if I mentioned it before, but the error for -dev tk is:
|
|  tk_init: this isn't a Tk application couldn't connect to display
|  "unix:0:0"
|  TCL command "plclient_link_end" failed:
|  		invalid command name "plclient_link_end"

And are you able to start tk applications? Such as a simple "wish"?
   jcard@...: wish
   %

Joao

|
|
|
|
|  Could it be version related? I have 8.4.1 installed.
|
|
|  - Koen.
|
|
|
|  -------------------------------------------------------
|  This SF.net email is sponsored by: IBM Linux Tutorials.
|  Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
|  Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
|  Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
|  _______________________________________________
|  Plplot-devel mailing list
|  Plplot-devel@...
|  https://lists.sourceforge.net/lists/listinfo/plplot-devel

On Jan 2, 2004, at 11:41 PM, Jo=E3o Cardoso wrote:

> And are you able to start tk applications? Such as a simple "wish"?
>    jcard@...: wish
>    %
>
>

Yes, that works, but only from an X-window, not from the command line.=20=

The result is a small empty window titled 'wish'. The examples from=20
plplot still give an error from an X-window when directed to tk (to=20
xwin works fine).

- Koen.

On Jan 1, 2004, at 11:56 AM, Alan W. Irwin wrote:

> As a test of tcl/tk you could also try the new tk device -dev ntk 
> which you
> also run from the command-line.  It might work because my 
> understanding is
> ntk device is implemented in a less complicated way than the tk 
> device, but
> OTOH the ntk device capabilities have not been developed yet to the 
> same level
> that is available with the tk device.
>

Just tested that again from an X-window, and ./x01c -dev ntk does work! 
I forgot if I tried it that way before, or maybe it has to do with the 
pthreads-issue.

- Koen.

I am not sure I undersood all the exchanges concerning the pthreads
problem on Mac OS X.

I made the following trial:

---- modification of xwin.c ---
#ifdef HAVE_PTHREAD
#include <pthread.h>
#include <signal.h>
int    pthread_mutexattr_setkind_np(pthread_mutexattr_t *attr, int kind);
static void events_thread(void *pls);
static pthread_mutex_t events_mutex;
static int already =3D 0;
#endif

    #define __APPLE__
    #ifdef __APPLE__
    #define PTHREAD_MUTEX_RECURSIVE_NP      PTHREAD_MUTEX_RECURSIVE
    #define pthread_mutexattr_setkind_np    pthread_mutexattr_setkind
    #endif


/* Device info */
char* plD_DEVICE_INFO_xwin =3D "xwin:X-Window (Xlib):1:xwin:5:xw";

------- configure -----
command:        ./configure --with-pthreads --disable-dyndrivers
--disable-f77
system:         powerpc-apple-darwin7.2.0

------- make fails with the following error ------
(xwin.c compiles without error)

gcc -dynamiclib  -o .libs/libplplotd.9.0.0.dylib  .libs/pdfutils.o
=2Elibs/plargs.o .libs/plbox.o .libs/plcont.o .libs/plcore.o .libs/plctrl.o
=2Elibs/plcvt.o .libs/pldtik.o .libs/plfill.o .libs/plfreetype.o
=2Elibs/plhist.o .libs/plimage.o .libs/plline.o .libs/plmap.o .libs/plot3d.=
o
=2Elibs/plpage.o .libs/plsdef.o .libs/plshade.o .libs/plstripc.o
=2Elibs/plsym.o .libs/pltick.o .libs/plvpor.o .libs/plwind.o .libs/plbuf.o
=2Elibs/plgridd.o -all_load  ../drivers/.libs/libplplotdrv.a
=2E./lib/csa/.libs/libcsirocsa.dylib -L/usr/X11R6/lib -lX11 -lpthread -lm
-install_name  /usr/local/lib/libplplotd.9.dylib -compatibility_version 10
-current_version 10.0
ld: warning -dylib_install_name /usr/local/lib/libplplotd.9.dylib not
found in segment address table LD_SEG_ADDR_TABLE
/sw/var/lib/fink/prebound/seg_addr_table
ld: warning prebinding disabled because of undefined symbols
ld: Undefined symbols:
_pthread_mutexattr_setkind
/usr/bin/libtool: internal link edit command failed
make[2]: *** [libplplotd.la] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

---------

 Sorry to fill your mail box if this test was not useful!

Michel




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Michel Peyrard, Professeur       % Ph: +33 (0)4 7272 8374            %
% Laboratoire de Physique          % Fax: +33 (0)4 7272 8080           %
% Ecole Normale Sup=E9rieure de Lyon % e-mail:Michel.Peyrard@... %
% 46 all=E9e d'Italie                % perso.ens-lyon.fr/michel.peyrard  %
% 69364 Lyon Cedex 07, France      % (GPG key available on home page)  %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

On Jan 4, 2004, at 4:49 AM, Michel Peyrard wrote:

>
>  I am not sure I undersood all the exchanges concerning the pthreads
> problem on Mac OS X.
>
> I made the following trial:
>
> ---- modification of xwin.c ---
> #ifdef HAVE_PTHREAD
> #include <pthread.h>
> #include <signal.h>
> int    pthread_mutexattr_setkind_np(pthread_mutexattr_t *attr, int 
> kind);
> static void events_thread(void *pls);
> static pthread_mutex_t events_mutex;
> static int already = 0;
> #endif
>
>     #define __APPLE__
>     #ifdef __APPLE__
>     #define PTHREAD_MUTEX_RECURSIVE_NP      PTHREAD_MUTEX_RECURSIVE
>     #define pthread_mutexattr_setkind_np    pthread_mutexattr_setkind
>     #endif
>

Michel,

Try putting the #define __APPLE__ section above the #ifdef HAVE_PTHREAD 
section.

And change

#define pthread_mutexattr_setkind_np    pthread_mutexattr_setkind
to
#define pthread_mutexattr_setkind_np    pthread_mutexattr_settype

Also, the line #define __APPLE__ is not really necessary, I think.

- Koen.

Using the modified xwin.c below, and make F77="g77 -lcc_dynamic" to take
care of the fortran problem, I can compile the tarball 20031231 with
pthreads and shared-libs, including fortran, on Mac OSX.

 (I am not sure that the exit from the program works normally, however.
The xwindow seems to persist and I have to close it by hand; but, as I am
doing X through a modem, it is very slow and this could be at the origin
of the problem)

 It seems that the only problem that persits on Mac OSX is the need
to disable dyndrivers.

 Michel

---- modified xwin.c -----
        PLplot X-windows device driver.
*/
#include "plDevs.h"

#define DEBUG

#ifdef PLD_xwin
#define NEED_PLDEBUG
#include "plplotP.h"
#include "plxwd.h"
#include "drivers.h"
#include "plevent.h"

     #ifdef __APPLE__
     #define PTHREAD_MUTEX_RECURSIVE_NP      PTHREAD_MUTEX_RECURSIVE
     #define pthread_mutexattr_setkind_np    pthread_mutexattr_settype
     #endif


#ifdef HAVE_PTHREAD
#include <pthread.h>
#include <signal.h>