plplot-general — PLplot user discussion group

[Plplot-general] Numeric label problem

[Kaj W. <kaj...@ik...>]

Hi!

There seems to be a bug in the algorithm that determines the numeric
labes for axes. It is easier to show than explain.. This code:

use PDL;
use PDL::Graphics::PLplot;

plinit();
plenv(2003, 2005, 2003, 2005, 0, 0);
plend;

produces these labels:

                   |
  2005        +
                   |
  2005        +
                   |
  2004        +
                   |
  2004        +
                   |
  2003   ----+--------+--------+--------+--------+---
                2003    2004     2004     2005     2005

I guess they should read "2003  2003.5  2004  2004.5  2005".

Any suggestions?

Thanks,
Kaj

Re: [Plplot-general] Numeric label problem

[Kaj W. <kaj...@ik...>]

Forgot to mention library version:
5.6.1-11ubuntu1 (gutsy)

2008/3/5, Kaj Wiik <kaj...@ik...>:
> Hi!
>
>  There seems to be a bug in the algorithm that determines the numeric
>  labes for axes. It is easier to show than explain.. This code:
>
>  use PDL;
>  use PDL::Graphics::PLplot;
>
>  plinit();
>  plenv(2003, 2005, 2003, 2005, 0, 0);
>  plend;
>
>  produces these labels:
>
>                    |
>   2005        +
>                    |
>   2005        +
>                    |
>   2004        +
>                    |
>   2004        +
>                    |
>   2003   ----+--------+--------+--------+--------+---
>                 2003    2004     2004     2005     2005
>
>  I guess they should read "2003  2003.5  2004  2004.5  2005".
>
>  Any suggestions?
>
>  Thanks,
>
> Kaj
>

[Plplot-general] OCaml bindings update

[Hezekiah M. C. <hc...@at...>]

I would like to announce an update to my PLplot [1] library bindings
for OCaml.

The code can be downloaded from:
http://code.google.com/p/ocaml-plplot/

The main changes for this release are:
- Works now with camlidl from Debian and other non-GODI* installs.  The
 previous release had problems on non-GODI OCaml installations.
- More or less complete coverage of PLplot 5.8.0 functions.  If anything is
 missing or needed, please let me know.
- The version number has changed to match the corresponding PLplot version

Requirements:
- OCaml (tested with 3.10.0, should work on older versions?)
- PLplot version 5.7.x or 5.8.x - tested with 5.7.3 through 5.8.0
- camlidl
- findlib

The license is the same as PLplot (LGPLv2+).

This code has been developed and tested on Debian Sid and CentOS 5,
using both GODI and Debian OCaml packages.  I would be happy to hear
about any successes or failures on other systems.

There are currently two examples included [2], which corresponds to
examples 11 and 19 on the PLplot website [1].  The PLplot documentation [3]
is a good reference as this binding is very close to the C library.
There is some documentation available on the ocaml-plplot Google Code wiki
as well.  Please feel free to ask if you have any questions, problems or
requests.

Enjoy!

* GODI is an OCaml installation and package management system

[1] - http://plplot.sourceforge.net/

[2] - http://code.google.com/p/ocaml-plplot/source/browse/trunk/examples/x11.ml
and http://code.google.com/p/ocaml-plplot/source/browse/trunk/examples/x19.ml

[3] - http://plplot.sourceforge.net/docbook-manual/

-- 
Hezekiah M. Carty
Graduate Research Assistant
University of Maryland
Department of Atmospheric and Oceanic Science

Re: [Plplot-general] plAlloc2dGrid()

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

On Saturday, March 1, 2008 at 07:15:12 (-0600) Maurice LeBrun writes:
 > On Friday, February 29, 2008 at 10:46:02 (+0000) Andrew Ross writes:
 >  > ...
 >  > The reason (not an excuse!) that these functions are not documented is
 >  > that they are not part of our common API. They are only used in the C
 >  > examples and are provided as a convenience. Plplot just uses standard C
 >  > 2-d arrays. You can allocate and free these yourself using malloc / 
 >  > free if you like. Of course other languages have their own way of 
 >  > allocating arrays and so don't need these functions for the other
 >  > bindings. 
 > 
 > A caveat: these are not quite the same thing as "standard C 2-d arrays",
 > that is if you mean the result of:
 > 
 >     PLFLT f[nx][ny];
 > 
 > These are a poor substitute for a real type, which should either know its
 > dimensions or at least be addressable without carrying extra baggage along.

Sorry for the misuse of English.  From this point on I am talking about
plAlloc2dGrid() style storage only.

 > So instead of an array of pointers to PLFLT, this is an array of an array of
 > pointers to PLFLT (right about now the Fortran folks are probably shuddering).
 > 
 > While convenient, it's also a lousy data storage layout for high-speed trips
 > through an inner loop due to stride issues.  No problem -- store the data
 > however you want in your code for maximum efficiency, and then copy it to one
 > of these plAlloc2dGrid style arrays when getting ready to plot.  Or use one of
 > the function evaluator approaches to lookup your data in its native format.
 > 
 >  * plAlloc2dGrid() 
 >  * 
 >  * Allocates a block of memory for use as a 2-d grid of PLFLT's. 
 >  * Resulting array can be indexed as f[i][j] anywhere.  This is to be used 
 >  * instead of PLFLT f[nx][ny], which is less useful.  Note that this type 
 >  * of allocation is required by the PLplot functions which take a 2-d 
 >  * grids of PLFLT's as an argument, such as plcont() and plot3d(). 
 >  * Example usage: 
 >  * 
 >  *   PLFLT **z; 
 >  * 
 >  *   Alloc2dGrid(&z, XPTS, YPTS); 
 > 
 >  > Having said that, we should document them. Thanks for pointing this out.
 >  > 
 >  > Andrew
 > 
 > -- 
 > Maurice LeBrun
 > 
 > -------------------------------------------------------------------------
 > This SF.net email is sponsored by: Microsoft
 > Defy all challenges. Microsoft(R) Visual Studio 2008.
 > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
 > _______________________________________________
 > Plplot-general mailing list
 > Plp...@li...
 > https://lists.sourceforge.net/lists/listinfo/plplot-general

-- 
Maurice LeBrun

Re: [Plplot-general] plAlloc2dGrid()

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

On Friday, February 29, 2008 at 10:46:02 (+0000) Andrew Ross writes:
 > ...
 > The reason (not an excuse!) that these functions are not documented is
 > that they are not part of our common API. They are only used in the C
 > examples and are provided as a convenience. Plplot just uses standard C
 > 2-d arrays. You can allocate and free these yourself using malloc / 
 > free if you like. Of course other languages have their own way of 
 > allocating arrays and so don't need these functions for the other
 > bindings. 

A caveat: these are not quite the same thing as "standard C 2-d arrays",
that is if you mean the result of:

    PLFLT f[nx][ny];

These are a poor substitute for a real type, which should either know its
dimensions or at least be addressable without carrying extra baggage along.
So instead of an array of pointers to PLFLT, this is an array of an array of
pointers to PLFLT (right about now the Fortran folks are probably shuddering).

While convenient, it's also a lousy data storage layout for high-speed trips
through an inner loop due to stride issues.  No problem -- store the data
however you want in your code for maximum efficiency, and then copy it to one
of these plAlloc2dGrid style arrays when getting ready to plot.  Or use one of
the function evaluator approaches to lookup your data in its native format.

 * plAlloc2dGrid() 
 * 
 * Allocates a block of memory for use as a 2-d grid of PLFLT's. 
 * Resulting array can be indexed as f[i][j] anywhere.  This is to be used 
 * instead of PLFLT f[nx][ny], which is less useful.  Note that this type 
 * of allocation is required by the PLplot functions which take a 2-d 
 * grids of PLFLT's as an argument, such as plcont() and plot3d(). 
 * Example usage: 
 * 
 *   PLFLT **z; 
 * 
 *   Alloc2dGrid(&z, XPTS, YPTS); 

 > Having said that, we should document them. Thanks for pointing this out.
 > 
 > Andrew

-- 
Maurice LeBrun

Re: [Plplot-general] plAlloc2dGrid()

[Andrew R. <and...@us...>]

On Fri, Feb 29, 2008 at 11:10:30AM +0100, Arjen Markus wrote:
> Oliver Bandel wrote:
> 
> >Hello,
> >
> >in Example 11 I found graphics, which looks similar to what I
> >wanted to have.
> >
> >I browsed through the code and found
> >plAlloc2dGrid().
> >In tge pdf-version of the documentation I found it mentioned one time,
> >but without any description.
> >In the online html-version I didn't found it.
> >
> >
> >Possibly the examples reason is, to better understand
> >how to use plplot-lib, but when the examples use
> >non-documented functions, they do not really help...
> >
> >Are their additional ressources somewhere, which I can
> >look at ( I do not mean the plplot-lib sources, maybe
> >some more documentation)?!
> >
> >Ciao,
> >   Oliver
> >
> >P.S.: The same problem I found for:
> >  plMinMax2dGrid()
> >   and
> >  plFree2dGrid()
> >  
> >
> Hello Oliver,
> 
> the documentation certainly could do with a bit of work.
> I do not think there is more information about the use of
> these routines/functions beyond what you have already
> found. But as these functions have a simple interface,
> illustrated by the examples, can you understand their
> use or do you need a more detailed description right
> now? (The documentation will have to extended,
> I agree).

Oliver,

The reason (not an excuse!) that these functions are not documented is
that they are not part of our common API. They are only used in the C
examples and are provided as a convenience. Plplot just uses standard C
2-d arrays. You can allocate and free these yourself using malloc / 
free if you like. Of course other languages have their own way of 
allocating arrays and so don't need these functions for the other
bindings. 

Having said that, we should document them. Thanks for pointing this out.

Andrew

Re: [Plplot-general] plAlloc2dGrid()

[Arjen M. <arj...@wl...>]

Oliver Bandel wrote:

>Hello,
>
>in Example 11 I found graphics, which looks similar to what I
>wanted to have.
>
>I browsed through the code and found
>plAlloc2dGrid().
>In tge pdf-version of the documentation I found it mentioned one time,
>but without any description.
>In the online html-version I didn't found it.
>
>
>Possibly the examples reason is, to better understand
>how to use plplot-lib, but when the examples use
>non-documented functions, they do not really help...
>
>Are their additional ressources somewhere, which I can
>look at ( I do not mean the plplot-lib sources, maybe
>some more documentation)?!
>
>Ciao,
>   Oliver
>
>P.S.: The same problem I found for:
>  plMinMax2dGrid()
>   and
>  plFree2dGrid()
>  
>
Hello Oliver,

the documentation certainly could do with a bit of work.
I do not think there is more information about the use of
these routines/functions beyond what you have already
found. But as these functions have a simple interface,
illustrated by the examples, can you understand their
use or do you need a more detailed description right
now? (The documentation will have to extended,
I agree).

Regards,

Arjen

[Plplot-general] plAlloc2dGrid()

[Oliver B. <ol...@fi...>]

Hello,

in Example 11 I found graphics, which looks similar to what I
wanted to have.

I browsed through the code and found
plAlloc2dGrid().
In tge pdf-version of the documentation I found it mentioned one time,
but without any description.
In the online html-version I didn't found it.


Possibly the examples reason is, to better understand
how to use plplot-lib, but when the examples use
non-documented functions, they do not really help...

Are their additional ressources somewhere, which I can
look at ( I do not mean the plplot-lib sources, maybe
some more documentation)?!

Ciao,
   Oliver

P.S.: The same problem I found for:
  plMinMax2dGrid()
   and
  plFree2dGrid()

Re: [Plplot-general] using plplot as a library in xwindows apps

[Werner S. <sm...@ia...>]

Hi Fons,

I don't have any direct link for you, but I somehow remember that 
someone gave an example regarding your problem on the mailing list. You 
could search in the mailing list, maybe here:

http://www.mail-archive.com/plp...@li.../
http://www.mail-archive.com/plp...@li.../

HTH,
Werner

Fons Adriaensen wrote:
> Hello all,
> 
> 
> I'm a complete newbie as regards Plplot and installed
> it just a few hours ago (on a Linux system). Everything
> compiled OK, the examples are working.
> 
> Now I'm trying to find out how to use Plplot purely
> as a plotting library in existing X11 apps.
> 
> What I need is a function that will draw a 3D plot to
> window or a pixmap using either the basic X11 backend
> or Cairo, and nothing more. Setting up any resources
> and calling the function at the right time is the
> application's responsability. The drawing routing is
> not expected to create the window, wait for X events
> etc., and in fact must not do any of this.
> 
> The examples are not of any help here as everything
> is hidden, I guess in plinit(). The manual doesn't
> touch on the subject except for the GTK canvas but
> I'm not using GTK. 
> 
> Is there any documentation or example code to explain
> or show what is required ?
> 
> Many thanks.
> 


-- 
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: sm...@ia...
web:   http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
        +43-(0)1-58801-13469 (laboratory)
fax:   +43-(0)1-58801-13499

Re: [Plplot-general] rotated graphics brings missing part of graphics

[Werner S. <sm...@ia...>]

Hi Oliver,
> 
> I looked into the ref-man now,
> and there was mentioned that it is intended to use it
> with values 0, 1, 2, and 3.
> But why not an int-value for that? The design is not clear here.
> If there is the possibility to have floating poibnt values,
> they should be supported, IMHO.

The manual states: "Note, arbitrary rotation parameters such as 0.2 
(corresponding to 18) are possible, but the usual
values for the rotation parameter are 0., 1., 2., and 3. corresponding 
to 0 (landscape mode), 90
(portrait mode), 180 (seascape mode), and 270 (upside-down mode)
"

Maybe we should add to the manual that values, which are not 0,1,2,3, 
are only for experimental use. So, floats make sense, but this feature 
is still buggy.

> P.S.: I have found other bugs too, a while ago, and maybe I will
>       send them to this list also. The above one was one of the
>       first few I found.

It would be very helpful, if you find the time to send the bugs to the 
list - plplot will only become better, if we know what goes wrong for 
the user (and than try to fix it).

Regards,
Werner

> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general


-- 
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: sm...@ia...
web:   http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
        +43-(0)1-58801-13469 (laboratory)
fax:   +43-(0)1-58801-13499

[Plplot-general] using plplot as a library in xwindows apps

[Fons A. <fo...@ko...>]

Hello all,


I'm a complete newbie as regards Plplot and installed
it just a few hours ago (on a Linux system). Everything
compiled OK, the examples are working.

Now I'm trying to find out how to use Plplot purely
as a plotting library in existing X11 apps.

What I need is a function that will draw a 3D plot to
window or a pixmap using either the basic X11 backend
or Cairo, and nothing more. Setting up any resources
and calling the function at the right time is the
application's responsability. The drawing routing is
not expected to create the window, wait for X events
etc., and in fact must not do any of this.

The examples are not of any help here as everything
is hidden, I guess in plinit(). The manual doesn't
touch on the subject except for the GTK canvas but
I'm not using GTK. 

Is there any documentation or example code to explain
or show what is required ?

Many thanks.

-- 
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.

[Plplot-general] PLplot 5.9.0 is now available

[Hazen B. <hba...@ma...>]

Hello,

The 5.9.0 development release of PLplot is now available. This  
release includes a number of improvements including (1) All auto- 
tools related files have now been removed (2) Date and time labels  
for axes (3) Code cleanup and bug fixes (4) Alpha (or transparency)  
value support and (5) WxWidgets driver improvements. Development  
releases in the 5.9.x series will be available in the coming months  
and the next stable release will be 5.10.0.

As always, (1) Please refer to our wiki for the latest build and  
install instructions (http://www.miscdebris.net/plplot_wiki/index.php? 
title=Main_Page) and (2) Let us know of any problems / bugs that you  
run across while installing / using PLplot.

best,
-Hazen

Re: [Plplot-general] rotated graphics brings missing part of graphics

[Oliver B. <ol...@fi...>]

Zitat von "Alan W. Irwin" <ir...@be...>:
[...]
>
> Did you really want to rotate your results by 0.4*90 = 36 degrees?

Yes.

Not, that I have a reason to do it in the real world right now,
but possibly sometimes I might need it.
I wanted to see, if i works correctly, and it does not.

[...]
> If not,
> comment out the "plsdiori(0.4);" line in your code and you should
> probably
> be okay.

[...]

If there is a floating point value to select the orientation,
it should be possible to use it with floats.

I looked into the ref-man now,
and there was mentioned that it is intended to use it
with values 0, 1, 2, and 3.
But why not an int-value for that? The design is not clear here.
If there is the possibility to have floating poibnt values,
they should be supported, IMHO.

Ciao,
   Oliver

P.S.: I have found other bugs too, a while ago, and maybe I will
      send them to this list also. The above one was one of the
      first few I found.

Re: [Plplot-general] rotated graphics brings missing part of graphics

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

On 2008-02-09 11:32+0100 Oliver Bandel wrote:

> Hello,
>
> when using this example code,
> I got graphics that are rotated
> and where also parts of the graics are
> missing.

You can get the rotation effect with any of the standard examples (such as
example 5 which uses plhist) by using the command-line option "-ori 0.4"
which is equivalent to the "plsdiori(0.4);" that occurs in your code.  But
non-integral values such as 0.4 are considered experimental.  When I use
"-ori 0.4" with example 5, the rotated corners of the plot are cutoff
because they don't fit into the original area.

Did you really want to rotate your results by 0.4*90 = 36 degrees?  If not,
comment out the "plsdiori(0.4);" line in your code and you should probably
be okay.

Alan
__________________________
Alan W. Irwin

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

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-general] rotated graphics brings missing part of graphics

[Oliver B. <ol...@fi...>]

Hello,

when using this example code,
I got graphics that are rotated,
and where also parts of the graics are
missing.

This is experimental code, so it possibly contains
unused code and could be done nicer,
but that was, what I used...
...I didnt' wanted to make it cleaner, because by accident I might
throw out the part that makes the problem.

It seems to be a problem of the plplot-lib,
that the graphics is not displayed correctly.
Or did I missed something in the initialization
to make that working?

Ciao,
   Oliver

And now the code:

====================================================================
#include <stdio.h>
#include <stdlib.h>

#include <plplot.h>


static PLFLT data_size_pflt[1] = {0.0};
static PLFLT x_data[100] = {0.0, 10.0, 20.0};
static PLFLT y_data[100] = {0.0, 12.0, 33.0,
   4096.0,
   2901.0,
    202.0,
      0.0,
   1615.0,
   6756.0,
   5578.0,
    585.0,
   1626.0,
 };



int main( int argc, char* argv[] )
{
  int idx = 0;

  /* set up data */
  for( idx = 0; idx < sizeof(x_data) / sizeof(data_size_pflt); idx++ )
  {
    x_data[idx] = 10.0 * idx;
  }


  if( 0 )
  {
    plsetopt("dev", "png");
    plsetopt("o",   "out.png");
  }
  else
  {
    plsetopt("dev", "ps");
    plsetopt("o",   "out.ps");
  }

  plsetopt( "-geometry", "1024x800" );
  plssub(2,2);

  plscolbg (255, 255,240);

  plsdiori(0.4);

  /* ******************************************************** */
  /*                        INIT                              */
  /* ******************************************************** */
  plinit();
  plcol1(0.4);


  plenv(0,100, 0, 10000.0, 0, 0);

  pllab("erste", "zweite", "dritte");

  /*
  */

  plptex(50,200, 0.0, 0.0,   0, "Guten Abend");
  plptex(50,400, 30.0, 0.0,   0, "Guten Abend");
  plptex(50,600, 0.0, 30.0,   0, "Guten Abend");

  pljoin( 20,44, 82, 1000);

  /* DATA plotting */

  plline(12, x_data, y_data);


  /* ----------------------------------------- */
  plcol1(0.2);
    plenv(0,100, 0, 10000.0, 0, 0);
    pllab("erste", "zweite", "dritte");

  plcol1(0.4);
    plptex(50,200, 0.0, 0.0,   0, "asjkdfh");

    /* DATA plotting */

    pljoin( 20,44, 82, 1000);
    plline(12, x_data, y_data);
  /* ----------------------------------------- */

  plcol1(0.1);

    plhist(12, y_data, 0, 10000, 100, PL_HIST_DEFAULT);


  plend();

  return 0;
}
====================================================================


__END__

Re: [Plplot-general] PLplot on OSX and wxwidgets

[Werner S. <sm...@ia...>]

Ok,

just to close (?) this topic.
>
> Werner, does that change solve the issue?  If not, then perhaps  
> libwxwidgets
> and libgd as currently installed on your system are linked to  
> different jpeg
> and png libraries, and you may have to reinstall one or both of them  
> to
> use consistent jpeg and png libraries if the Mac OS X linker and run- 
> time
> loader is not smart enough to handle that situation.

this partly solves my issues. CMAKE_LIBRARY_PATH and  
CMAKE_INCLUDE_PATH are the first in the search paths for the cmake  
modules and if I set them to /opt/local/lib and /opt/local/include  
respectively cmake happily find all macports libraries. If I don't do  
that cmake gets confused:

It is impossible to order the linker search path in such a way that  
libraries specified as full paths will be picked by the linker.
Directories and libraries involved are:
Directory: /opt/local/lib contains:
Library: /usr/lib/libltdl.dylib

Directory: /usr/X11/lib contains:
Library: /opt/local/lib/libXrender.dylib
Library: /opt/local/lib/libfontconfig.dylib
Library: /opt/local/lib/libfreetype.dylib
Library: /opt/local/lib/libpng12.dylib

Directory: /usr/X11R6/lib contains:
Library: /opt/local/lib/libXrender.dylib
Library: /opt/local/lib/libfontconfig.dylib
Library: /opt/local/lib/libfreetype.dylib
Library: /opt/local/lib/libpng12.dylib

Directory: /usr/lib contains:
Library: /opt/local/lib/libexpat.dylib
Library: /opt/local/lib/libiconv.dylib
Library: /opt/local/lib/libz.dylib

After I set the CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH enviroment  
variables it compiles. If I compile the static library I get link  
errors regarding the wxwidgets.o object file:

Undefined symbols:
   "___cxa_guard_release", referenced from:
       wxPLplotWindow::OnIdle(wxIdleEvent&)       in  
libplplotd.a(wxwidgets.o)
   "operator delete[](void*)", referenced from:
       fill_polygon(PLStream*)     in libplplotd.a(wxwidgets.o)
       agg::pod_allocator<unsigned char>::deallocate(unsigned char*,  
unsigned int)in libplplotd.a(wxwidgets.o)
        
agg 
::pod_allocator 
<agg::scanline_u8::span>::deallocate(agg::scanline_u8::span*, unsigned  
int)in libplplotd.a(wxwidgets.o)
       agg::pod_allocator<agg::cell_aa>::deallocate(agg::cell_aa*,  
unsigned int)in libplplotd.a(wxwidgets.o)
       agg::pod_allocator<agg::cell_aa*>::deallocate(agg::cell_aa**,  
unsigned int)in libplplotd.a(wxwidgets.o)
        
agg::pod_allocator<agg::vertex_dist>::deallocate(agg::vertex_dist*,  
unsigned int)in libplplotd.a(wxwidgets.o)
        
agg::pod_allocator<agg::vertex_dist*>::deallocate(agg::vertex_dist**,  
unsigned int)in libplplotd.a(wxwidgets.o)
       agg::pod_allocator<agg::point_base<double>  
 >::deallocate(agg::point_base<double>*, unsigned int)in  
libplplotd.a(wxwidgets.o)
        
agg 
::pod_allocator 
<agg::point_base<double>*>::deallocate(agg::point_base<double>**,  
unsigned int)in libplplotd.a(wxwidgets.o)
        
agg 
::pod_allocator 
< 
agg 
::rasterizer_cells_aa 
< 
agg 
::cell_aa 
 > 
::sorted_y 
 >::deallocate(agg::rasterizer_cells_aa<agg::cell_aa>::sorted_y*,  
unsigned int)in libplplotd.a(wxwidgets.o)
       agg::pod_allocator<double>::deallocate(double*, unsigned int)in  
libplplotd.a(wxwidgets.o)
       agg::pod_allocator<double*>::deallocate(double**, unsigned  
int)in libplplotd.a(wxwidgets.o)
   "___cxa_end_catch", referenced from:
       wxRunApp(PLStream*, bool)in libplplotd.a(wxwidgets.o)
       install_buffer(PLStream*)     in libplplotd.a(wxwidgets.o)
   "operator delete(void*)", referenced from:
       wxPLCreateApp()     in libplplotd.a(wxwidgets.o)
       plD_tidy_wxwidgets(PLStream*)     in libplplotd.a(wxwidgets.o)
       plD_tidy_wxwidgets(PLStream*)     in libplplotd.a(wxwidgets.o)
       wxPLplotFrame::wxPLplotFrame(wxString const&, PLStream*)in  
libplplotd.a(wxwidgets.o)
       wxPLplotFrame::wxPLplotFrame(wxString const&, PLStream*)in  
libplplotd.a(wxwidgets.o)

It complains about symbols normally provided by the standard c++  
library? So either this library is not linked in (why?) or C/C++ mixup  
or ... no idea. Disabling the wxwidgets driver let plplot compile and  
also there are no(t many) problems executing the examples, that is,  
aqt/xwin/xcairo have actually problems, but png and others work.

Regards,
Werner


>
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and  
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state  
> implementation
> for stellar interiors (freeeos.sf.net); PLplot scientific plotting  
> software
> package (plplot.org); the libLASi project (unifont.org/lasi); the  
> Loads of
> Linux Links project (loll.sf.net); and the Linux Brochure Project
> (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: sm...@ia...
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499

Re: [Plplot-general] PNGs are fully transparent (i.e. no image)

[Andrew R. <and...@us...>]

Torquil,

There are some limitations with the gd driver support for transparency.
One of those is that 8-bit doesn't work well. It is generally best to
stick to 24-bit truecolor. Having said that, this sounds like it might
be a bug to me. I will try to investigate further.

Andrew

On Tue, Feb 05, 2008 at 09:08:24PM +0100, Torquil Macdonald S?rensen wrote:
> Hello, I had this working before but for some reason I now get fully 
> transparent PNG files, i.e. with no images in them, for all _except_ the first 
> PNG file I generate. E.g. the program below makes a good 1.png, but 
> 2.png is just transparent (pnginfo says all the colours used in it are 
> transparent). I know this because if I use "optimise", it says e.g. "2 
> colours, 2 transparent". Everything works fine when not using the 8bit 
> option.
> 
> Best regards,
> Torquil S?rensen
> 
> ********* "pnginfo" has the following to say about 1.png and 2.png: ***
> 
> 1.png...
>   Image Width: 800 Image Length: 600
>   Bitdepth (Bits/Sample): 8
>   Channels (Samples/Pixel): 1
>   Pixel depth (Pixel Depth): 8
>   Colour Type (Photometric Interpretation): PALETTED COLOUR (256 colours, 0 
> transparent)
>   Image filter: Single row per byte filter
>   Interlacing: No interlacing
>   Compression Scheme: Deflate method 8, 32k window
>   Resolution: 0, 0 (unit unknown)
>   FillOrder: msb-to-lsb
>   Byte Order: Network (Big Endian)
>   Number of text strings: 0 of 0
>   Offsets: 0, 0
> 
> 2.png...
>   Image Width: 800 Image Length: 600
>   Bitdepth (Bits/Sample): 8
>   Channels (Samples/Pixel): 1
>   Pixel depth (Pixel Depth): 8
>   Colour Type (Photometric Interpretation): PALETTED COLOUR with alpha (256 
> colours, 144 transparent)
>   Image filter: Single row per byte filter
>   Interlacing: No interlacing
>   Compression Scheme: Deflate method 8, 32k window
>   Resolution: 0, 0 (unit unknown)
>   FillOrder: msb-to-lsb
>   Byte Order: Network (Big Endian)
>   Number of text strings: 0 of 0
>   Offsets: 0, 0
> 
> ****************** Here is the program: ********************
> 
> #include <plplot/plplot.h>
> using namespace std;
> 
> int main()
> {
> plsdev("xwin"); // Screen plot
> plinit();
> plenv(0, 1, 0, 1, 1, -2);
> 
> plsstrm(1); plsdev("png"); // PNG plot
> plsfam(1,0,1); plsfnam("%n.png");
> plsetopt("drvopt", "8bit");
> plinit();
> plenv(0, 1, 0, 1, 1, -2);
> 
> double x[] = {0.0, 1.0}, y[] = {0.0, 0.5};
> 
> plsstrm(0);
> plbop(); plline(2, x, y); pleop();
> 	
> plsstrm(1); plcpstrm(0, 1);
> plbop(); plreplot(); pleop();
> 
> plsstrm(0);
> plbop(); plline(2, y, x); pleop();
> 
> plsstrm(1); plcpstrm(0, 1);
> plbop(); plreplot(); pleop();
> 
> plend();
> return(0);
> }
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
> 

Re: [Plplot-general] plsetopt() order matters for png driver

[Torquil M. S. <to...@gm...>]

Hallo Werner,

Thanks for your solution, it is working better with plspage(). Somehow I did 
not notice that function when browsing through the different methods of 
setting up the plot window... But maybe the documentation could be altered 
slightly:

plspage (xp, yp, xleng, yleng, xoff, yoff);

xp (PLFLT, input) Number of pixels, x. 
yp (PLFLT, input) Number of pixels, y. 
xleng (PLINT , input) Page length, x. 
yleng (PLINT, input) Page length, y. 
xoff (PLINT, input) Page offset, x. 
yoff (PLINT, input) Page offset, y.

The first two should maybe not say "Number of pixels", but something like

"Pixels per inch, x"

and maybe the variable names should be xdpi and ydpi (not really important). 
The second pair could be 

"Number of pixels, x"    or    "Page length (pixels), x"

The last pair could maybe be something like

"Page offset (pixels), x".

Best regards,
Torquil Sørensen

On Monday 04 February 2008, Werner Smekal wrote:
> Hi Torquil,
>
> as Alan I can also reproduce this behaviour. I scanned through the
> code, but it needs some time to find out what's going on. Anyway, a
> workaround for this problem is, that you set the common plplot options
> not via plsetopt(), but via plplot commands directly. E.g. if you set
> the geometry option actually plspage (xdpi, ydpi, xwid, ywid, xoff,
> yoff); is called. so -geometry 400x300 would ne
> plspage(0,0,400,300,0,0);. Have a look at src/plargs.c for other
> options. If you need to set more than one driver options you can call
> e.g plsetopt( "drvopt", "8bit,smoothlines"). Therefore you should be
> able to circumvent this problem you mentioned.
>
> HTH,
> Werner
>
> On 03.02.2008, at 21:48, Torquil Macdonald Sørensen wrote:
> > Hello, I have found that the order in which I call plsetopt()
> > matters. Using
> > plsetopt("drvopt","8bit") before plsetopt("geometry","800x600")
> > makes PLplot
> > forget about the 8bit option and use 24bit instead (I use the png
> > driver). I
> > have checked the png-files using pnginfoto determine if they are
> > 8bit or
> > 24bit. Setting "geometry" before "8bit" works fine. On the command
> > line it
> > works either way.
> >
> > Best regards,
> > Torquil Sørensen
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Plplot-general mailing list
> > Plp...@li...
> > https://lists.sourceforge.net/lists/listinfo/plplot-general
>
> --
> Dr. Werner Smekal
> Institut fuer Allgemeine Physik
> Technische Universitaet Wien
> Wiedner Hauptstr 8-10
> A-1040 Wien
> Austria
>
> email: sm...@ia...
> web: http://www.iap.tuwien.ac.at/~smekal
> phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
> fax: +43-(0)1-58801-13499
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general

[Plplot-general] plimage color scale

[Hezekiah M. C. <hc...@at...>]

I am currently attempting to use the plimage function to display
several different intensity maps.  The function seems to work
properly, and the images are displayed as I would generally expect.
However, I would like to keep the color scale the same across each
plot, such that a given intensity value always displays with the same
color.  From what I can tell, plimage seems to automatically adjust to
color scale to evenly cover the range of provided data.

Is there a way to get around this, and force plimage to always plot
(for example) a value of 0.0 as the color 0.0 and a value of 1.0 as
the color 1.0?  Without this it makes comparison between plots much
more difficult.

I am using PLplot 5.8.0 and have read through the plimage source code,
but it is not clear to me if this is possible with the function as-is.

Hez

-- 
Hezekiah M. Carty
Graduate Research Assistant
University of Maryland
Department of Atmospheric and Oceanic Science

[Plplot-general] PNGs are fully transparent (i.e. no image)

[Torquil M. S. <to...@gm...>]

Hello, I had this working before but for some reason I now get fully 
transparent PNG files, i.e. with no images in them, for all _except_ the first 
PNG file I generate. E.g. the program below makes a good 1.png, but 
2.png is just transparent (pnginfo says all the colours used in it are 
transparent). I know this because if I use "optimise", it says e.g. "2 
colours, 2 transparent". Everything works fine when not using the 8bit 
option.

Best regards,
Torquil Sørensen

********* "pnginfo" has the following to say about 1.png and 2.png: ***

1.png...
  Image Width: 800 Image Length: 600
  Bitdepth (Bits/Sample): 8
  Channels (Samples/Pixel): 1
  Pixel depth (Pixel Depth): 8
  Colour Type (Photometric Interpretation): PALETTED COLOUR (256 colours, 0 
transparent)
  Image filter: Single row per byte filter
  Interlacing: No interlacing
  Compression Scheme: Deflate method 8, 32k window
  Resolution: 0, 0 (unit unknown)
  FillOrder: msb-to-lsb
  Byte Order: Network (Big Endian)
  Number of text strings: 0 of 0
  Offsets: 0, 0

2.png...
  Image Width: 800 Image Length: 600
  Bitdepth (Bits/Sample): 8
  Channels (Samples/Pixel): 1
  Pixel depth (Pixel Depth): 8
  Colour Type (Photometric Interpretation): PALETTED COLOUR with alpha (256 
colours, 144 transparent)
  Image filter: Single row per byte filter
  Interlacing: No interlacing
  Compression Scheme: Deflate method 8, 32k window
  Resolution: 0, 0 (unit unknown)
  FillOrder: msb-to-lsb
  Byte Order: Network (Big Endian)
  Number of text strings: 0 of 0
  Offsets: 0, 0

****************** Here is the program: ********************

#include <plplot/plplot.h>
using namespace std;

int main()
{
plsdev("xwin"); // Screen plot
plinit();
plenv(0, 1, 0, 1, 1, -2);

plsstrm(1); plsdev("png"); // PNG plot
plsfam(1,0,1); plsfnam("%n.png");
plsetopt("drvopt", "8bit");
plinit();
plenv(0, 1, 0, 1, 1, -2);

double x[] = {0.0, 1.0}, y[] = {0.0, 0.5};

plsstrm(0);
plbop(); plline(2, x, y); pleop();
	
plsstrm(1); plcpstrm(0, 1);
plbop(); plreplot(); pleop();

plsstrm(0);
plbop(); plline(2, y, x); pleop();

plsstrm(1); plcpstrm(0, 1);
plbop(); plreplot(); pleop();

plend();
return(0);
}

Re: [Plplot-general] PLplot on OSX and wxwidgets

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

On 2008-02-05 11:07+0100 Werner Smekal wrote:

> I hope all FindXXX.cmake scripts always look in CMAKE_LIBRARY_PATH
> first, before trying the standard paths, or?

Yes.  If you check the FindXXX.cmake modules installed with your system you
will see they virtually always use the CMake FIND_LIBRARY command to find
libraries.  Unless specifically told otherwise, that command uses the
environment variable CMAKE_LIBRARY_PATH before system paths for searches,
see the full documentation of FIND_LIBRARY at
http://www.cmake.org/HTML/Documentation.html.

Good luck with your further tests once you get access to your Mac system.

Alan
__________________________
Alan W. Irwin

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

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] PLplot on OSX and wxwidgets

[Werner S. <sm...@ia...>]

Hi Alan
>
> I follow the above argument this far. If you turn dynamic drivers off 
> (which
> is a necessary side effect of the -DBUILD_SHARED_LIBS=OFF option or which
> you can specify independently for the shared libraries case by using the
> -DENABLE_DYNDRIVERS=OFF option), then instead of being used as 
> independent
> plug-ins all driver code becomes part of our core library.  In that
> all-in-one case, you have the wxwidgets driver code using the wxwidgets
> library and the gd driver using the gd library, i.e., our core library 
> links
> to both the wxwidgets and gd libraries, but NOT directly to the jpeg 
> or png
> libraries since our device drivers do not refer to jpeg or png 
> symbols.  So
> this is classical hierarchical linking with libplplot linking to 
> wxwidgets
> which in turn links to the jpeg and png libraries and similarly with
> libplplot linking to libgd which in turn links to the jpeg and png
> libraries.  If those two libraries link to two separate versions of 
> the jpeg
> and png libraries, that should not be an issue for a really smart library
> linking and run-time linking environment, but I am not sure whether 
> Mac OS X
> (or any other platform) is that smart or not.  In any case, how libgd and
> libwxwidgets are linked is completely outside of our build system's 
> control
> and something that the Mac OS X user may have to deal with 
> independently by
> reinstalling one or both of those libraries.
I think that's case. Mabye gcc is smart enough, since it issues only 
lots of warnings, but I wouldn't have a good feeling, that this will work :)
>
> Note, another complicating factor is our FindGD.cmake module finds 
> jpeg and
> png library information just in case the platform's linking and run-time
> environment is too dumb to even support hierarchical linking.  
> However, the
> CMake modules to find the jpeg and png libraries are completely 
> independent
> of each other and also of our own FindGD.cmake so it's quite possible 
> that
> FindGD.cmake is finding an inconsistent set of jpeg and png 
> libraries.  To
> change that behaviour set the environment variable CMAKE_LIBRARY_PATH 
> (see
> our wiki for more information on this variable) to the appropriate 
> path for
> the png and jpeg libraries needed by libgd.
I hope all FindXXX.cmake scripts always look in CMAKE_LIBRARY_PATH 
first, before trying the standard paths, or? Than I would just need to 
set them to /opt/local/lib which is were all macports libraries are. I 
would also need to set CMAKE_INCLUDE_PATH to /opt/local/include, so that 
the correct headers are used as well. I can test that on Thursday, until 
then I have no access to a Mac OS X machine.
>
> Werner, does that change solve the issue?  If not, then perhaps 
> libwxwidgets
> and libgd as currently installed on your system are linked to 
> different jpeg
> and png libraries, and you may have to reinstall one or both of them to
> use consistent jpeg and png libraries if the Mac OS X linker and run-time
> loader is not smart enough to handle that situation.
In any case I think if you mix the macports gd library with the 
wxwidgets library provided by apple, that this won't work (for the 
static case). Either one must compile wxwidgets on its own, using the 
macports libraries (wxWidgets uses them if it can find png and jpeg 
libraries, or turn png/jpeg support off) or use the macports wxwidgets 
library.

Thanks for the reminder about CMAKE_LIBRARY_PATH.

Regards,
Werner
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state 
> implementation
> for stellar interiors (freeeos.sf.net); PLplot scientific plotting 
> software
> package (plplot.org); the libLASi project (unifont.org/lasi); the 
> Loads of
> Linux Links project (loll.sf.net); and the Linux Brochure Project
> (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________

Re: [Plplot-general] [Plplot-devel] Segfault

[Werner S. <sm...@ia...>]

Hi Hans,

reading again your very first post, I see that you already described the 
problem into all its details :). Sorry for that, but the plplot core 
code is also new to me and I need some time to understand it.

Great that it works for you as well.
Regards,
Werner

Han...@sh... wrote:
> Hi Werner,
>
> The changes you made also fix my problems with the segmentation violation.
>
> Thanks,
> Hans Rijneke
>
> -----Original Message-----
> From: plp...@li...
> [mailto:plp...@li...]On Behalf Of Werner
> Smekal
> Sent: Friday, February 01, 2008 22:51
> To: plplot_general; PLplot development list
> Subject: Re: [Plplot-general] [Plplot-devel] Segfault
>
>
> Hi Andrew and Torquil,
>
> I made the decision to copy the whole (actually the part of the buffer 
> which contains information) buffer to a new memory buffer. Reason is, 
> that there is no obligation to close the stream right after you saved 
> the file. If the programmer decides to work on with both streams, both 
> streams write into the same buffer. Since nowadays memory is not that 
> problem anymore, I decided to copy the buffer. I couldn't test it 
> actually since on Windows there was no segmentation fault, but at least 
> the new version still compiles and runs on Windows. Could anybody 
> (Torquil?) test it, if the changes solve the problems?
>
> Regards,
> Werner
>   
>> I've just been looking at this bug too. We need the buffer - this is
>> what contains the copy of the plot commands for plreplot. The question
>> is should the copied stream have a copy of the buffer, or the actual
>> buffer. The old file buffer code seems to have used the actual file - so
>> by analogy we should have the actual buffer. If this is the case, then
>> we to have a reference counter for the buffer so we only free it once
>> all streams no longer reference it. The original buffer code goes way
>> back before my time with plplot. Does anyone still remember the original
>> intentions? Alan might recall.
>>
>> I'll leave any fix to you so we don't duplicate work. 
>>
>> Andrew
>>
>> P.S. I notice plstrm.h contains a plBufOwner variable to mark which
>> stream actually owns a buffer. Unfortunately this isn't used. It also
>> doesn't replace the reference counter because it doesn't stop a copy
>> accessing the buffer after it has been free'd.
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>     
>
>
>   

Re: [Plplot-general] [Plplot-devel] Segfault

[<Han...@sh...>]

Hi Werner,

The changes you made also fix my problems with the segmentation violation.

Thanks,
Hans Rijneke

-----Original Message-----
From: plp...@li...
[mailto:plp...@li...]On Behalf Of Werner
Smekal
Sent: Friday, February 01, 2008 22:51
To: plplot_general; PLplot development list
Subject: Re: [Plplot-general] [Plplot-devel] Segfault


Hi Andrew and Torquil,

I made the decision to copy the whole (actually the part of the buffer 
which contains information) buffer to a new memory buffer. Reason is, 
that there is no obligation to close the stream right after you saved 
the file. If the programmer decides to work on with both streams, both 
streams write into the same buffer. Since nowadays memory is not that 
problem anymore, I decided to copy the buffer. I couldn't test it 
actually since on Windows there was no segmentation fault, but at least 
the new version still compiles and runs on Windows. Could anybody 
(Torquil?) test it, if the changes solve the problems?

Regards,
Werner
> 
> I've just been looking at this bug too. We need the buffer - this is
> what contains the copy of the plot commands for plreplot. The question
> is should the copied stream have a copy of the buffer, or the actual
> buffer. The old file buffer code seems to have used the actual file - so
> by analogy we should have the actual buffer. If this is the case, then
> we to have a reference counter for the buffer so we only free it once
> all streams no longer reference it. The original buffer code goes way
> back before my time with plplot. Does anyone still remember the original
> intentions? Alan might recall.
> 
> I'll leave any fix to you so we don't duplicate work. 
> 
> Andrew
> 
> P.S. I notice plstrm.h contains a plBufOwner variable to mark which
> stream actually owns a buffer. Unfortunately this isn't used. It also
> doesn't replace the reference counter because it doesn't stop a copy
> accessing the buffer after it has been free'd.
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel


-- 
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: sm...@ia...
web:   http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
        +43-(0)1-58801-13469 (laboratory)
fax:   +43-(0)1-58801-13499

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Plplot-general mailing list
Plp...@li...
https://lists.sourceforge.net/lists/listinfo/plplot-general

Re: [Plplot-general] PLplot on OSX and wxwidgets

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

On 2008-02-04 10:20+0100 Werner Smekal wrote:

> Hi Ty,
>
> you can get rid of the tk warnings by gettting rid of the tk driver,
> which you don't need anyway by setting the cmake option -
> DENABLE_tk=OFF and -DENABLE-tcl=OFF. The other warnings you get are
> since there is a mixup between the png/jpeg libraries installed by
> macport to /opt/local/ and the ones provided by the wxWidgets library.
> I actually have similar problems and need to find a way how I tell
> cmake which library/headers it should use. In the shared case this is
> not a problem, since the wxWidgets library knows which dylib to use,
> but if you link all together many symbols are twice in the linked
> object.

Hi Werner:

I follow the above argument this far. If you turn dynamic drivers off (which
is a necessary side effect of the -DBUILD_SHARED_LIBS=OFF option or which
you can specify independently for the shared libraries case by using the
-DENABLE_DYNDRIVERS=OFF option), then instead of being used as independent
plug-ins all driver code becomes part of our core library.  In that
all-in-one case, you have the wxwidgets driver code using the wxwidgets
library and the gd driver using the gd library, i.e., our core library links
to both the wxwidgets and gd libraries, but NOT directly to the jpeg or png
libraries since our device drivers do not refer to jpeg or png symbols.  So
this is classical hierarchical linking with libplplot linking to wxwidgets
which in turn links to the jpeg and png libraries and similarly with
libplplot linking to libgd which in turn links to the jpeg and png
libraries.  If those two libraries link to two separate versions of the jpeg
and png libraries, that should not be an issue for a really smart library
linking and run-time linking environment, but I am not sure whether Mac OS X
(or any other platform) is that smart or not.  In any case, how libgd and
libwxwidgets are linked is completely outside of our build system's control
and something that the Mac OS X user may have to deal with independently by
reinstalling one or both of those libraries.

Note, another complicating factor is our FindGD.cmake module finds jpeg and
png library information just in case the platform's linking and run-time
environment is too dumb to even support hierarchical linking.  However, the
CMake modules to find the jpeg and png libraries are completely independent
of each other and also of our own FindGD.cmake so it's quite possible that
FindGD.cmake is finding an inconsistent set of jpeg and png libraries.  To
change that behaviour set the environment variable CMAKE_LIBRARY_PATH (see
our wiki for more information on this variable) to the appropriate path for
the png and jpeg libraries needed by libgd.

Werner, does that change solve the issue?  If not, then perhaps libwxwidgets
and libgd as currently installed on your system are linked to different jpeg
and png libraries, and you may have to reinstall one or both of them to
use consistent jpeg and png libraries if the Mac OS X linker and run-time
loader is not smart enough to handle that situation.

Alan
__________________________
Alan W. Irwin

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

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________