plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] fortran example compile error

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

On 2015-04-24 16:51-0600 Orion Poplawski wrote:

> # make
> /usr/bin/gfortran  x00f.f90 -o x00f  -I/usr/include/plplot
> -I/usr/lib64/gfortran/modules -I/usr/include/plplot -lplplotf95  -lplf95demolib
> /usr/bin/ld: /tmp/ccNUjhko.o: undefined reference to symbol 'plinit_'
> /usr/lib64/libplplotf95c.so.12: error adding symbols: DSO missing from command
> line
> collect2: error: ld returned 1 exit status
> # grep -Fi plinit x00f.f90
>    call plinit
>
> /usr/lib64/libplplotf95c.so
> 0000000000009350 T plinit_
>
> So we need to link with -lplplotf95c

Hi Orion:

Thanks for all the reports.  I thought the comprehensive testing (done
only on Debian derivative distros) was a little light for the release
of 5.11.0 but good enough.  However, it appears now from your results
that testing was not extended to enough Linux platforms.

Anyhow, just keep reporting any other build-system issues you find for
the case of Fedora to plplot-devel like you have been doing, and I
will respond as soon as possible with fixes with the goal of
completely cleaning up the situation on Fedora before the next release
of PLplot (which may be as soon as end of June if that release is
going to be devoted to bug fixes alone).

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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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-devel] PDL-Graphics-PLplot and plplot 5.11.0

[Doug H. <dh...@uc...>]

Hi Orion:  Thanks for the patch.  I'll look into this next week and try 
to put out
an updated PDL-Graphics-PLplot.

Regards,

   Doug Hunt

On 04/24/15 16:34, Orion Poplawski wrote:
> I'm trying to build PDL-Graphics-PLplot 0.67 with plplot 5.11.0.  First I need
> the attached patch to handle the name change.
>
> Next issue I'm running into is the plplot.t test segfaulting:
>
> $ LD_LIBRARY_PATH=../blib/arch/auto/PDL/Graphics/PLplot/ gdb perl
> GNU gdb (GDB) Fedora 7.9-11.fc23
> Copyright (C) 2015 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from perl...Reading symbols from
> /home/orion/fedora/perl-PDL-Graphics-PLplot/PDL-Graphics-PLplot-0.67/t/perl...(no
> debugging symbols found)...done.
> (no debugging symbols found)...done.
> Missing separate debuginfos, use: dnf debuginfo-install
> perl-5.20.2-328.fc23.x86_64
> (gdb) run -I../blib/lib ./plplot.t
> Starting program: /usr/bin/perl -I../blib/lib ./plplot.t
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Detaching after fork from child process 26859.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff2fd66fa in plP_state (op=op@entry=7)
>      at /usr/src/debug/plplot-5.11.0/src/plcore.c:260
> 260             ( *plsc->dispatch_table->pl_state )( (struct PLStream_struct
> *) plsc, op );
> (gdb) bt
> #0  0x00007ffff2fd66fa in plP_state (op=op@entry=7)
>      at /usr/src/debug/plplot-5.11.0/src/plcore.c:260
> #1  0x00007ffff2ff4e84 in c_plschr (def=<optimized out>, scale=<optimized out>)
>      at /usr/src/debug/plplot-5.11.0/src/plsdef.c:209
> #2  0x00007ffff32e1ab2 in pdl_plschr_readdata (__tr=0x15924e0) at PLplot.xs:11154
> #3  0x00007ffff55a6194 in pdl.ensure_trans ()
>     from /usr/lib64/perl5/vendor_perl/auto/PDL/Core/Core.so
> #4  0x00007ffff55a5150 in pdl_make_trans_mutual ()
>     from /usr/lib64/perl5/vendor_perl/auto/PDL/Core/Core.so
> #5  0x00007ffff32ababf in XS_PDL_plschr (my_perl=<optimized out>,
> cv=<optimized out>)
>      at PLplot.xs:50441
> #6  0x00007ffff7aea6ab in Perl_pp_entersub () from /lib64/libperl.so.5.20
> #7  0x00007ffff7ae2f36 in Perl_runops_standard () from /lib64/libperl.so.5.20
> #8  0x00007ffff7a729c0 in perl_run () from /lib64/libperl.so.5.20
> #9  0x0000000000400d79 in main ()
> (gdb) list
> 255             plbuf_state( plsc, op );
> 256
> 257         save_locale = plsave_set_locale();
> 258         if ( !plsc->stream_closed )
> 259         {
> 260             ( *plsc->dispatch_table->pl_state )( (struct PLStream_struct
> *) plsc, op );
> 261         }
> 262         plrestore_locale( save_locale );
> 263     }
> 264
> (gdb) print plsc
> $1 = (PLStream *) 0x7ffff321eaa0 <pls0>
> (gdb) print op
> $2 = 7
> (gdb) print plsc->dispatch_table
> $3 = (PLDispatchTable *) 0x0
> (gdb) print *plsc
> $2 = {ipls = 0, level = 0, verbose = 0, debug = 0, initialized = 0,
> dev_initialized = 0,
>    program = 0x0, coordinate_transform = 0x0, coordinate_transform_data = 0x0,
> icol0 = 0,
>    ncol0 = 16, icol1 = 0, ncol1 = 0, ncp1 = 0, curcmap = 0, cmap1_min = 0,
> cmap1_max = 0,
>    curcolor = {r = 0 '\000', g = 0 '\000', b = 0 '\000', a = 0, name = 0x0},
> tmpcolor = {
>      r = 0 '\000', g = 0 '\000', b = 0 '\000', a = 0, name = 0x0}, cmap0 =
> 0x155e310,
>    cmap1 = 0x0, cmap1cp = {{h = 0, l = 0, s = 0, p = 0, a = 0,
>        alt_hue_path = 0} <repeats 256 times>}, width = 0, widthset = 0,
> widthlock = 0,
>    arrow_x = 0x0, arrow_y = 0x0, arrow_npts = 0, arrow_fill = 0, dispatch_table
> = 0x0,
>    plbuf_read = 0, plbuf_write = 0, device = 0, dev_minor = 0, termin = 0,
> graphx = 0,
>    nopause = 0, color = 0, colorset = 0, family = 0, member = 0, finc = 0,
> fflen = 0,
>    bytemax = 0, famadv = 0, dev_fill0 = 0, dev_fill1 = 0, dev_dash = 0, dev_di = 0,
>    dev_flush = 0, dev_swin = 0, dev_text = 0, dev_xor = 0, dev_clear = 0,
> dev_fastimg = 0,
>    dev_arc = 0, DevName = "xfig", '\000' <repeats 75 times>, OutFile = 0x0,
>    BaseName = 0x151a800 "test2.xfig", FileName = 0x155e2d0 "test2.xfig",
> output_type = 0,
>    bytecnt = 0, page = 0, linepos = 0, pdfs = 0x0, dev_npts = 0, dev_x = 0x0,
> dev_y = 0x0,
>    dev_nptsX = 0, dev_nptsY = 0, dev_ix = 0x0, dev_iy = 0x0, dev_z = 0x0,
> dev_zmin = 0,
>    dev_zmax = 0, imclxmin = 0, imclxmax = 0, imclymin = 0, imclymax = 0, dev = 0x0,
>    dev_data = 0x0, KeyEH = 0x0, KeyEH_data = 0x0, ButtonEH = 0x0, ButtonEH_data
> = 0x0,
>    LocateEH = 0x0, LocateEH_data = 0x0, bop_handler = 0x0, bop_data = 0x0,
> eop_handler = 0x0,
>    eop_data = 0x0, xdpi = 0, ydpi = 0, xlength = 0, ylength = 0, xoffset = 0,
> yoffset = 0,
>    pageset = 0, hack = 0, tidy = 0x0, tidy_data = 0x0, errcode = 0x0, errmsg = 0x0,
>    geometry = 0x0, window_id = 0, nopixmap = 0, db = 0, ext_resize_draw = 0,
> server_name = 0x0,
>    server_host = 0x0, server_port = 0x0, user = 0x0, plserver = 0x0, plwindow =
> 0x0,
>    auto_path = 0x0, tk_file = 0x0, bufmax = 0, dp = 0, server_nokill = 0,
>    plbuf_buffer_grow = 0, plbuf_buffer_size = 0, plbuf_buffer = 0x0, plbuf_top = 0,
>    plbuf_readpos = 0, plbufOwner = 0, difilt = 0, diclpxmi = 0, diclpxma = 0,
> diclpymi = 0,
>    diclpyma = 0, dipxmin = 0, dipymin = 0, dipxmax = 0, dipymax = 0, dipxax =
> 0, dipxb = 0,
>    dipyay = 0, dipyb = 0, aspdev = 0, aspect = 0, aspori = 0, caspfactor = 0,
> mar = 0, jx = 0,
>    jy = 0, didxax = 0, didxb = 0, didyay = 0, didyb = 0, diorot = 0, dioxax =
> 0, dioxay = 0,
>    dioxb = 0, dioyax = 0, dioyay = 0, dioyb = 0, dimxax = 0, dimxb = 0, dimyay
> = 0, dimyb = 0,
>    dimxmin = 0, dimymin = 0, dimxmax = 0, dimymax = 0, dimxpmm = 0, dimypmm = 0,
>    page_status = 0, freeaspect = 0, portrait = 0, patt = 0, inclin = {0, 0},
> delta = {0, 0},
>    nps = 0, currx = 0, curry = 0, mark = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, space
> = {0, 0, 0, 0,
>      0, 0, 0, 0, 0, 0}, nms = 0, timecnt = 0, alarm = 0, pendn = 0, curel = 0,
> esc = 0 '\000',
>    scale = 0, chrdef = 0, chrht = 0, symdef = 0, symht = 0, majdef = 0, majht =
> 0, mindef = 0,
>    minht = 0, setpre = 0, precis = 0, xdigmax = 0, ydigmax = 0, zdigmax = 0,
> xdigits = 0,
>    ydigits = 0, zdigits = 0, timefmt = 0x0, label_func = 0x0, label_data = 0x0,
> vppxmi = 0,
>    vppxma = 0, vppymi = 0, vppyma = 0, sppxmi = 0, sppxma = 0, sppymi = 0,
> sppyma = 0,
>    clpxmi = 0, clpxma = 0, clpymi = 0, clpyma = 0, phyxmi = 0, phyxma = 0,
> phyxlen = 0,
>    phyymi = 0, phyyma = 0, phyylen = 0, umx = 0, umy = 0, xpmm = 0, ypmm = 0,
> base3x = 0,
>    base3y = 0, basecx = 0, basecy = 0, domxmi = 0, domxma = 0, domymi = 0,
> domyma = 0,
>    zzscl = 0, ranmi = 0, ranma = 0, cxx = 0, cxy = 0, cyx = 0, cyy = 0, cyz =
> 0, czx = 0,
>    czy = 0, czz = 0, nplwin = 0, plwin = {{dxmi = 0, dxma = 0, dymi = 0, dyma =
> 0, wxmi = 0,
>        wxma = 0, wymi = 0, wyma = 0} <repeats 64 times>}, nsubx = 0, nsuby = 0,
> cursub = 0,
>    spdxmi = 0, spdxma = 0, spdymi = 0, spdyma = 0, vpdxmi = 0, vpdxma = 0,
> vpdymi = 0,
>    vpdyma = 0, vpwxmi = 0, vpwxma = 0, vpwymi = 0, vpwyma = 0, wpxscl = 0,
> wpxoff = 0,
>    wpyscl = 0, wpyoff = 0, wmxscl = 0, wmxoff = 0, wmyscl = 0, wmyoff = 0,
> wdxscl = 0,
>    wdxoff = 0, wdyscl = 0, wdyoff = 0, dev_compression = 0, cfont = 0, FT = 0x0,
>    plPlotterPtr = 0x0, dev_unicode = 0, alt_unicode = 0, fci = 0, dev_hrshsym = 0,
>    original_chrdef = 0, original_chrht = 0, psdoc = 0x0, qsasconfig = 0x0,
> dev_gradient = 0,
>    ngradient = 0, xgradient = 0x0, ygradient = 0x0, n_polygon = 0, x_polygon = 0x0,
>    y_polygon = 0x0, stream_closed = 0, line_style = 0, dev_mem_alpha = 0,
>    has_string_length = 0, string_length = 0, get_string_length = 0, dev_eofill = 0,
>    dev_modeset = 0, if_boxbb = 0, boxbb_xmin = 0, boxbb_xmax = 0, boxbb_ymin = 0,
>    boxbb_ymax = 0, mf_infile = 0x0, mf_outfile = 0x0}
>
>
> This seems to happen right away:
>
> use PDL;
> use PDL::Config;
> use PDL::Graphics::PLplot;
> use Test::More qw(no_plan);
>
> # Use xfig driver because it should always be installed.
> #my $dev = 'png';
> my $dev = 'xfig';
>
> # redirect STDERR to purge silly 'opened *.xfig' messages
> my ($pl, $x, $y, $min, $max, $oldwin, $nbins);
>
> ###
> # Initial test to work around font file brain damage:  for some kinds of
> # PLplot errors, control never returns to us.  FMH.
> #   --CED
> ###
>
> my $tmpdir  = $PDL::Config{TEMPDIR} || "/tmp";
> my $tmpfile = $tmpdir . "/foo$$.$dev";
>
> $pl = PDL::Graphics::PLplot->new (DEV => $dev,
>                                    FILE => "test2.$dev",
>                                    BACKGROUND => [255,255,255]);
>
>
> Anything else to look for?
>
>

[Plplot-devel] fortran example compile error

[Orion P. <or...@co...>]

# make
/usr/bin/gfortran  x00f.f90 -o x00f  -I/usr/include/plplot
-I/usr/lib64/gfortran/modules -I/usr/include/plplot -lplplotf95  -lplf95demolib
/usr/bin/ld: /tmp/ccNUjhko.o: undefined reference to symbol 'plinit_'
/usr/lib64/libplplotf95c.so.12: error adding symbols: DSO missing from command
line
collect2: error: ld returned 1 exit status
# grep -Fi plinit x00f.f90
    call plinit

/usr/lib64/libplplotf95c.so
0000000000009350 T plinit_

So we need to link with -lplplotf95c

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                   http://www.nwra.com

[Plplot-devel] PDL-Graphics-PLplot and plplot 5.11.0

[Orion P. <or...@co...>]

I'm trying to build PDL-Graphics-PLplot 0.67 with plplot 5.11.0.  First I need
the attached patch to handle the name change.

Next issue I'm running into is the plplot.t test segfaulting:

$ LD_LIBRARY_PATH=../blib/arch/auto/PDL/Graphics/PLplot/ gdb perl
GNU gdb (GDB) Fedora 7.9-11.fc23
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from perl...Reading symbols from
/home/orion/fedora/perl-PDL-Graphics-PLplot/PDL-Graphics-PLplot-0.67/t/perl...(no
debugging symbols found)...done.
(no debugging symbols found)...done.
Missing separate debuginfos, use: dnf debuginfo-install
perl-5.20.2-328.fc23.x86_64
(gdb) run -I../blib/lib ./plplot.t
Starting program: /usr/bin/perl -I../blib/lib ./plplot.t
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Detaching after fork from child process 26859.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff2fd66fa in plP_state (op=op@entry=7)
    at /usr/src/debug/plplot-5.11.0/src/plcore.c:260
260             ( *plsc->dispatch_table->pl_state )( (struct PLStream_struct
*) plsc, op );
(gdb) bt
#0  0x00007ffff2fd66fa in plP_state (op=op@entry=7)
    at /usr/src/debug/plplot-5.11.0/src/plcore.c:260
#1  0x00007ffff2ff4e84 in c_plschr (def=<optimized out>, scale=<optimized out>)
    at /usr/src/debug/plplot-5.11.0/src/plsdef.c:209
#2  0x00007ffff32e1ab2 in pdl_plschr_readdata (__tr=0x15924e0) at PLplot.xs:11154
#3  0x00007ffff55a6194 in pdl.ensure_trans ()
   from /usr/lib64/perl5/vendor_perl/auto/PDL/Core/Core.so
#4  0x00007ffff55a5150 in pdl_make_trans_mutual ()
   from /usr/lib64/perl5/vendor_perl/auto/PDL/Core/Core.so
#5  0x00007ffff32ababf in XS_PDL_plschr (my_perl=<optimized out>,
cv=<optimized out>)
    at PLplot.xs:50441
#6  0x00007ffff7aea6ab in Perl_pp_entersub () from /lib64/libperl.so.5.20
#7  0x00007ffff7ae2f36 in Perl_runops_standard () from /lib64/libperl.so.5.20
#8  0x00007ffff7a729c0 in perl_run () from /lib64/libperl.so.5.20
#9  0x0000000000400d79 in main ()
(gdb) list
255             plbuf_state( plsc, op );
256
257         save_locale = plsave_set_locale();
258         if ( !plsc->stream_closed )
259         {
260             ( *plsc->dispatch_table->pl_state )( (struct PLStream_struct
*) plsc, op );
261         }
262         plrestore_locale( save_locale );
263     }
264
(gdb) print plsc
$1 = (PLStream *) 0x7ffff321eaa0 <pls0>
(gdb) print op
$2 = 7
(gdb) print plsc->dispatch_table
$3 = (PLDispatchTable *) 0x0
(gdb) print *plsc
$2 = {ipls = 0, level = 0, verbose = 0, debug = 0, initialized = 0,
dev_initialized = 0,
  program = 0x0, coordinate_transform = 0x0, coordinate_transform_data = 0x0,
icol0 = 0,
  ncol0 = 16, icol1 = 0, ncol1 = 0, ncp1 = 0, curcmap = 0, cmap1_min = 0,
cmap1_max = 0,
  curcolor = {r = 0 '\000', g = 0 '\000', b = 0 '\000', a = 0, name = 0x0},
tmpcolor = {
    r = 0 '\000', g = 0 '\000', b = 0 '\000', a = 0, name = 0x0}, cmap0 =
0x155e310,
  cmap1 = 0x0, cmap1cp = {{h = 0, l = 0, s = 0, p = 0, a = 0,
      alt_hue_path = 0} <repeats 256 times>}, width = 0, widthset = 0,
widthlock = 0,
  arrow_x = 0x0, arrow_y = 0x0, arrow_npts = 0, arrow_fill = 0, dispatch_table
= 0x0,
  plbuf_read = 0, plbuf_write = 0, device = 0, dev_minor = 0, termin = 0,
graphx = 0,
  nopause = 0, color = 0, colorset = 0, family = 0, member = 0, finc = 0,
fflen = 0,
  bytemax = 0, famadv = 0, dev_fill0 = 0, dev_fill1 = 0, dev_dash = 0, dev_di = 0,
  dev_flush = 0, dev_swin = 0, dev_text = 0, dev_xor = 0, dev_clear = 0,
dev_fastimg = 0,
  dev_arc = 0, DevName = "xfig", '\000' <repeats 75 times>, OutFile = 0x0,
  BaseName = 0x151a800 "test2.xfig", FileName = 0x155e2d0 "test2.xfig",
output_type = 0,
  bytecnt = 0, page = 0, linepos = 0, pdfs = 0x0, dev_npts = 0, dev_x = 0x0,
dev_y = 0x0,
  dev_nptsX = 0, dev_nptsY = 0, dev_ix = 0x0, dev_iy = 0x0, dev_z = 0x0,
dev_zmin = 0,
  dev_zmax = 0, imclxmin = 0, imclxmax = 0, imclymin = 0, imclymax = 0, dev = 0x0,
  dev_data = 0x0, KeyEH = 0x0, KeyEH_data = 0x0, ButtonEH = 0x0, ButtonEH_data
= 0x0,
  LocateEH = 0x0, LocateEH_data = 0x0, bop_handler = 0x0, bop_data = 0x0,
eop_handler = 0x0,
  eop_data = 0x0, xdpi = 0, ydpi = 0, xlength = 0, ylength = 0, xoffset = 0,
yoffset = 0,
  pageset = 0, hack = 0, tidy = 0x0, tidy_data = 0x0, errcode = 0x0, errmsg = 0x0,
  geometry = 0x0, window_id = 0, nopixmap = 0, db = 0, ext_resize_draw = 0,
server_name = 0x0,
  server_host = 0x0, server_port = 0x0, user = 0x0, plserver = 0x0, plwindow =
0x0,
  auto_path = 0x0, tk_file = 0x0, bufmax = 0, dp = 0, server_nokill = 0,
  plbuf_buffer_grow = 0, plbuf_buffer_size = 0, plbuf_buffer = 0x0, plbuf_top = 0,
  plbuf_readpos = 0, plbufOwner = 0, difilt = 0, diclpxmi = 0, diclpxma = 0,
diclpymi = 0,
  diclpyma = 0, dipxmin = 0, dipymin = 0, dipxmax = 0, dipymax = 0, dipxax =
0, dipxb = 0,
  dipyay = 0, dipyb = 0, aspdev = 0, aspect = 0, aspori = 0, caspfactor = 0,
mar = 0, jx = 0,
  jy = 0, didxax = 0, didxb = 0, didyay = 0, didyb = 0, diorot = 0, dioxax =
0, dioxay = 0,
  dioxb = 0, dioyax = 0, dioyay = 0, dioyb = 0, dimxax = 0, dimxb = 0, dimyay
= 0, dimyb = 0,
  dimxmin = 0, dimymin = 0, dimxmax = 0, dimymax = 0, dimxpmm = 0, dimypmm = 0,
  page_status = 0, freeaspect = 0, portrait = 0, patt = 0, inclin = {0, 0},
delta = {0, 0},
  nps = 0, currx = 0, curry = 0, mark = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, space
= {0, 0, 0, 0,
    0, 0, 0, 0, 0, 0}, nms = 0, timecnt = 0, alarm = 0, pendn = 0, curel = 0,
esc = 0 '\000',
  scale = 0, chrdef = 0, chrht = 0, symdef = 0, symht = 0, majdef = 0, majht =
0, mindef = 0,
  minht = 0, setpre = 0, precis = 0, xdigmax = 0, ydigmax = 0, zdigmax = 0,
xdigits = 0,
  ydigits = 0, zdigits = 0, timefmt = 0x0, label_func = 0x0, label_data = 0x0,
vppxmi = 0,
  vppxma = 0, vppymi = 0, vppyma = 0, sppxmi = 0, sppxma = 0, sppymi = 0,
sppyma = 0,
  clpxmi = 0, clpxma = 0, clpymi = 0, clpyma = 0, phyxmi = 0, phyxma = 0,
phyxlen = 0,
  phyymi = 0, phyyma = 0, phyylen = 0, umx = 0, umy = 0, xpmm = 0, ypmm = 0,
base3x = 0,
  base3y = 0, basecx = 0, basecy = 0, domxmi = 0, domxma = 0, domymi = 0,
domyma = 0,
  zzscl = 0, ranmi = 0, ranma = 0, cxx = 0, cxy = 0, cyx = 0, cyy = 0, cyz =
0, czx = 0,
  czy = 0, czz = 0, nplwin = 0, plwin = {{dxmi = 0, dxma = 0, dymi = 0, dyma =
0, wxmi = 0,
      wxma = 0, wymi = 0, wyma = 0} <repeats 64 times>}, nsubx = 0, nsuby = 0,
cursub = 0,
  spdxmi = 0, spdxma = 0, spdymi = 0, spdyma = 0, vpdxmi = 0, vpdxma = 0,
vpdymi = 0,
  vpdyma = 0, vpwxmi = 0, vpwxma = 0, vpwymi = 0, vpwyma = 0, wpxscl = 0,
wpxoff = 0,
  wpyscl = 0, wpyoff = 0, wmxscl = 0, wmxoff = 0, wmyscl = 0, wmyoff = 0,
wdxscl = 0,
  wdxoff = 0, wdyscl = 0, wdyoff = 0, dev_compression = 0, cfont = 0, FT = 0x0,
  plPlotterPtr = 0x0, dev_unicode = 0, alt_unicode = 0, fci = 0, dev_hrshsym = 0,
  original_chrdef = 0, original_chrht = 0, psdoc = 0x0, qsasconfig = 0x0,
dev_gradient = 0,
  ngradient = 0, xgradient = 0x0, ygradient = 0x0, n_polygon = 0, x_polygon = 0x0,
  y_polygon = 0x0, stream_closed = 0, line_style = 0, dev_mem_alpha = 0,
  has_string_length = 0, string_length = 0, get_string_length = 0, dev_eofill = 0,
  dev_modeset = 0, if_boxbb = 0, boxbb_xmin = 0, boxbb_xmax = 0, boxbb_ymin = 0,
  boxbb_ymax = 0, mf_infile = 0x0, mf_outfile = 0x0}


This seems to happen right away:

use PDL;
use PDL::Config;
use PDL::Graphics::PLplot;
use Test::More qw(no_plan);

# Use xfig driver because it should always be installed.
#my $dev = 'png';
my $dev = 'xfig';

# redirect STDERR to purge silly 'opened *.xfig' messages
my ($pl, $x, $y, $min, $max, $oldwin, $nbins);

###
# Initial test to work around font file brain damage:  for some kinds of
# PLplot errors, control never returns to us.  FMH.
#   --CED
###

my $tmpdir  = $PDL::Config{TEMPDIR} || "/tmp";
my $tmpfile = $tmpdir . "/foo$$.$dev";

$pl = PDL::Graphics::PLplot->new (DEV => $dev,
                                  FILE => "test2.$dev",
                                  BACKGROUND => [255,255,255]);


Anything else to look for?


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                   http://www.nwra.com

[Plplot-devel] c++ wxWidget example compile issue

[Orion P. <or...@co...>]

I should not that these are with the installed examples:

/usr/bin/c++ wxPLplotDemo.cpp -o wxPLplotDemo  -D_FILE_OFFSET_BITS=64
-D_LARGE_FILES -D__WXGTK__ -I/usr/include/plplot
-I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8
-I/usr/include/plplot -lplplotwxwidgets
wxPLplotDemo.cpp:138:1: warning: ‘virtual wxLog*
wxAppConsole::CreateLogTarget()’ is deprecated [-Wdeprecated-declarations]
 }
 ^
In file included from /usr/include/wx-2.8/wx/wxprec.h:13:0,
                 from wxPLplotDemo.cpp:22:
/usr/include/wx-2.8/wx/app.h:184:34: note: declared here
     wxDEPRECATED( virtual wxLog *CreateLogTarget() );
                                  ^
/usr/include/wx-2.8/wx/defs.h:513:29: note: in definition of macro ‘wxDEPRECATED’
     #define wxDEPRECATED(x) x __attribute__ ((deprecated))
                             ^
wxPLplotDemo.cpp:138:1: warning: ‘virtual wxMessageOutput*
wxAppConsole::CreateMessageOutput()’ is deprecated [-Wdeprecated-declarations]
 }
 ^
In file included from /usr/include/wx-2.8/wx/wxprec.h:13:0,
                 from wxPLplotDemo.cpp:22:
/usr/include/wx-2.8/wx/app.h:189:44: note: declared here
     wxDEPRECATED( virtual wxMessageOutput *CreateMessageOutput() );
                                            ^
/usr/include/wx-2.8/wx/defs.h:513:29: note: in definition of macro ‘wxDEPRECATED’
     #define wxDEPRECATED(x) x __attribute__ ((deprecated))
                             ^
wxPLplotDemo.cpp:138:1: warning: ‘virtual void
wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated
[-Wdeprecated-declarations]
 }
 ^
In file included from /usr/include/wx-2.8/wx/wx.h:36:0,
                 from wxPLplotDemo.cpp:29:
/usr/include/wx-2.8/wx/window.h:1453:13: note: declared here
 inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
             ^
wxPLplotDemo.cpp:138:1: warning: ‘virtual void
wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated
[-Wdeprecated-declarations]
 }
 ^
In file included from /usr/include/wx-2.8/wx/wx.h:36:0,
                 from wxPLplotDemo.cpp:29:
/usr/include/wx-2.8/wx/window.h:1453:13: note: declared here
 inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
             ^
wxPLplotDemo.cpp:138:1: warning: ‘virtual void
wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated
[-Wdeprecated-declarations]
 }
 ^
In file included from /usr/include/wx-2.8/wx/wx.h:36:0,
                 from wxPLplotDemo.cpp:29:
/usr/include/wx-2.8/wx/window.h:1453:13: note: declared here
 inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
             ^
wxPLplotDemo.cpp:138:1: warning: ‘virtual void
wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated
[-Wdeprecated-declarations]
 }
 ^
In file included from /usr/include/wx-2.8/wx/wx.h:36:0,
                 from wxPLplotDemo.cpp:29:
/usr/include/wx-2.8/wx/window.h:1453:13: note: declared here
 inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
             ^
wxPLplotDemo.cpp:138:1: warning: ‘virtual void
wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated
[-Wdeprecated-declarations]
 }
 ^
In file included from /usr/include/wx-2.8/wx/wx.h:36:0,
                 from wxPLplotDemo.cpp:29:
/usr/include/wx-2.8/wx/window.h:1453:13: note: declared here
 inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
             ^
wxPLplotDemo.cpp:138:1: warning: ‘virtual void
wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated
[-Wdeprecated-declarations]
 }
 ^
In file included from /usr/include/wx-2.8/wx/wx.h:36:0,
                 from wxPLplotDemo.cpp:29:
/usr/include/wx-2.8/wx/window.h:1453:13: note: declared here
 inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
             ^
wxPLplotDemo.cpp:138:1: warning: ‘virtual void
wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated
[-Wdeprecated-declarations]
 }
 ^
In file included from /usr/include/wx-2.8/wx/wx.h:36:0,
                 from wxPLplotDemo.cpp:29:
/usr/include/wx-2.8/wx/window.h:1453:13: note: declared here
 inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
             ^
wxPLplotDemo.cpp:138:1: warning: ‘virtual void
wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated
[-Wdeprecated-declarations]
 }
 ^
In file included from /usr/include/wx-2.8/wx/wx.h:36:0,
                 from wxPLplotDemo.cpp:29:
/usr/include/wx-2.8/wx/window.h:1453:13: note: declared here
 inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
             ^
wxPLplotDemo.cpp:138:1: warning: ‘virtual void
wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated
[-Wdeprecated-declarations]
 }
 ^
In file included from /usr/include/wx-2.8/wx/wx.h:36:0,
                 from wxPLplotDemo.cpp:29:
/usr/include/wx-2.8/wx/window.h:1453:13: note: declared here
 inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
             ^
wxPLplotDemo.cpp:138:1: warning: ‘virtual void
wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated
[-Wdeprecated-declarations]
 }
 ^
In file included from /usr/include/wx-2.8/wx/wx.h:36:0,
                 from wxPLplotDemo.cpp:29:
/usr/include/wx-2.8/wx/window.h:1453:13: note: declared here
 inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
             ^
/usr/bin/ld: /tmp/ccH0vhU9.o: undefined reference to symbol
'_ZN8plstream4lineEiPKdS1_'
/usr/lib64/libplplotcxx.so.12: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Makefile:81: recipe for target 'wxPLplotDemo' failed

So it looks like something in either the wxPLplotDemo.cpp file or its includes
references the '_ZN8plstream4lineEiPKdS1_' symbol and so needs to be linked
with -lplplotcxx.  If it is wxPLplotDemo.cpp, then it should be added to the
Makefile like my other example.  If it the includes and so all
plplot-wxwidgets users need it, it should be added to the pkg-config output:

# pkg-config  --cflags --libs plplot-wxwidgets
-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -I/usr/include/plplot
-I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8
-I/usr/include/plplot -lplplotwxwidgets


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                   http://www.nwra.com

[Plplot-devel] C examples need to link to -lm

[Orion P. <or...@co...>]

The C examples use sin(), so they need to link with -lm:

diff --git a/examples/c/Makefile.examples.in b/examples/c/Makefile.examples.in
index bc47762..1764c4a 100644
--- a/examples/c/Makefile.examples.in
+++ b/examples/c/Makefile.examples.in
@@ -100,6 +100,6 @@ clean:
 @extcairo_true@        $(shell $(PKG_CONFIG_ENV) pkg-config
@PC_STATIC_OPTION@ --cflags --libs plplot cairo)

 .c$(EXEEXT):
-       $(CC) $< -o $@ $(RPATHCMD) $(shell $(PKG_CONFIG_ENV) pkg-config
@PC_STATIC_OPTION@ --cflags --libs plplot)
+       $(CC) $< -o $@ $(RPATHCMD) $(shell $(PKG_CONFIG_ENV) pkg-config
@PC_STATIC_OPTION@ --cflags --libs plplot) -lm

 .SUFFIXES: .c $(EXEEXT)

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                   http://www.nwra.com

Re: [Plplot-devel] Problems using the plplot cmake config file

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

On 2015-04-24 10:12-0600 Orion Poplawski wrote:

> It appears that due to the way the plplot cmake config file is currently
> constructed, in order to do a:
>
> find_package(plplot)
>
> You must have *every* built component installed or you get errors like:
>
> CMake Error at /usr/lib64/cmake/plplot/export_plplot.cmake:163 (message):
>  The imported target "plplot_octave" references the file
>
>     "/usr/lib64/octave/site/oct/x86_64-redhat-linux-gnu/plplot_octave.oct"
>
>  but this file does not exist.  Possible reasons include:
>
>
> And similar for:
>     "/usr/lib64/libplplotada.so.2.0.0"
>     "/usr/lib64/lua/5.3/plplot/plplotluac.so"
>     "/usr/lib64/python2.7/site-packages/plplot_pyqt4.so"
>     "/usr/lib64/libplf95demolib.a"
>
>
> For Fedora packaging we like to be able to split up packages based on
> dependencies so that people don't have to install components and dependencies
> that they don't need.
>
> I understand that the find_package config interface can take a COMPONENTS
> argument.  I don't know anything about how that is implemented, but perhaps
> that could be used to allow this?

Hi Orion:

As a result of the current way we export targets,
the files you should find in /usr/lib64/cmake/plplot/ are

export_plplot-noconfig.cmake,  export_plplot.cmake,  and plplotConfig.cmake

>From the documentation, find_package(plplot) in Config mode accesses
the plplotConfig.cmake file which then includes the
export_plplot.cmake file.  (Apparently export_plplot-noconfig.cmake is
not used for the present way we export our targets.)

I assume what you are trying to do is make a fully-loaded build of
PLplot and then split up the results into a bunch of different binary
packages, but if you look at export_plplot.cmake (which generated the
above error message) you can see the problem; it loops over all PLplot
targets that were exported in the fully-loaded build of PLplot and
errors out on the targets which you have attempted to split into
separate binary components.

Since split binary targets have been around from the early days of
rpm, I am pretty sure that CMake supports that idea when exporting
targets, but I currently don't know how to take advantage of such
CMake functionality if it exists.  So I will ask a question on the
CMake list about this.

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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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-devel] Problems using the plplot cmake config file

[Orion P. <or...@co...>]

It appears that due to the way the plplot cmake config file is currently
constructed, in order to do a:

find_package(plplot)

You must have *every* built component installed or you get errors like:

CMake Error at /usr/lib64/cmake/plplot/export_plplot.cmake:163 (message):
  The imported target "plplot_octave" references the file

     "/usr/lib64/octave/site/oct/x86_64-redhat-linux-gnu/plplot_octave.oct"

  but this file does not exist.  Possible reasons include:


And similar for:
     "/usr/lib64/libplplotada.so.2.0.0"
     "/usr/lib64/lua/5.3/plplot/plplotluac.so"
     "/usr/lib64/python2.7/site-packages/plplot_pyqt4.so"
     "/usr/lib64/libplf95demolib.a"


For Fedora packaging we like to be able to split up packages based on
dependencies so that people don't have to install components and dependencies
that they don't need.

I understand that the find_package config interface can take a COMPONENTS
argument.  I don't know anything about how that is implemented, but perhaps
that could be used to allow this?

Thanks.


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                   http://www.nwra.com

Re: [Plplot-devel] Incorrect pkg-config link flags with plplot 5.11.0

[Orion P. <or...@co...>]

On 04/23/2015 01:29 AM, Alan W. Irwin wrote:
> On 2015-04-22 22:44-0600 Orion Poplawski wrote:
> 
>> With plplot 5.10.0:
>>
>> # pkg-config plplotd --libs
>> -lplplotd
>>
>> With plplot 5.11.0:
>> -lplplot -lltdl -lm -lshp -lfreetype -lcsirocsa -lcsironn -lqhull -lqsastime
>>
>> # pkg-config plplot --libs
>>
>>
>> This is wrong because the extra libraries are only necessary in the case of
>> static linking.
> 
> Hi Orion:
> 
> As always, thanks for your useful PLplot input from the Fedora
> perspective.

You know, someday I'd like to get a one line response from you :)

> Let me define some terminology here (used by CMake documentation) to
> clarify my comments below. Non-transitive linking of an executable or
> library occurs when you only specify the libraries to the linker are
> needed to resolve symbols directly in the executable or library that
> is being built. In contrast, transitive linking is when you mention
> not only those libraries, but also all libraries that are required to
> resolve all symbols throughout the hierachy of library links.
> 
> The CMake documentation states that in all cases transitive linking
> should be used for the static case, and it is also safe to use that
> for the shared case but for platforms that support it, non-transitive
> linking can also be used for the shared library case.
> 
> To summarize what you have found in this terminology, our pkg-config results
> (which,
> of course, have nothing to do with CMake other than we configure those
> *.pc files with our CMake-based build system) follow those rules for the
> static case, but for the shared case, 5.10.0 used non-transitive
> linking while 5.11.0 used transitive linking (which apparently Fedora
> complains about even though it is always safe to use transitive linking).

Just to be clear, Fedora actively bans transitive linked for shared libraries.
 It leads to dependency bloat and other issues.

>> To indicate this use Libs.private.  See also
>> http://people.freedesktop.org/~dbn/pkg-config-guide.html
>>
>> The attached patch fixes.  If some functions are referenced directly in the
>> public plplot headers then you would need to add them to Libs.
> 
> I just checked the two relevant *.pc files from 5.10.0 and 5.11.0, and
> they are the same other than dropping the "d" suffix. So the change in
> pkg-config result must not be due to something being done differently
> by PLplot. Instead, my guess is Fedora is likely doing something
> different now with pkg-config.  For example, perhaps before they
> massaged pkg-config results but now they no longer do so more pkg-config
> transitive linking issues are revealed?

This is an incorrect assumption.  While the *.pc.in files are the same, the
way that you generate PC_LINK_FLAGS has obviously changed, and that is
producing the final difference in the generated *.pc file.  My F21 plplotd.pc
file has:

Libs: -L${libdir} -lplplotd

> That said, you are right (and actually the problem is likely more
> fundamental and pervasive then you have stated).  I just checked, and
> for 5.11.0 and many prior versions, the pkg-config file for a PLplot
> library has been configured using the flag used to link to the library
> as well as all flags necessary to link the library itself, i.e.,
> transitive linking from the point of view of some app trying to link
> to libplplot.  For example, both the 5.10.0 plplotd.pc file and the
> 5.11.0 plplot.pc file mention the link flags -lltdl -lm -lshp
> -lfreetype -lcsirocsa -lcsironn -lqhull -lqsastime on the Libs: line
> and do not mention Libs.private at all. Therefore, there has been a
> long-term fundamental PLplot pkg-config issue for the shared linking
> case for platforms that support non-transitive linking.
> 
> Another complication here is some platforms do not support
> non-transitive linking for the shared library case.  For those, the
> user must specify the -DNON_TRANSITIVE=OFF cmake option, and
> that has to be propagated correctly to our configured pkg-config
> files so they use non-transitive linking for the shared case
> only when that is allowed by -DNON_TRANSITIVE=ON.
> 
> Anyhow, I am virtually positive your patch involving Libs.private:
> will be part of the solution, but there is a lot to think about here
> and check before coming up with what I hope is the definitive solution
> for all the issues.  And I plan to do that early in this release cycle
> after dealing with a bunch of other build-system issues that have
> recently come to my attention (i.e., moving CMP0022 and CMP0023 from
> OLD to NEW, moving CMP0026 from old to new, dealing with double
> linking issues for tcl-related libraries when ENABLE_DYNDRIVERS=OFF,
> and updating epa_build).
> 
> Alan

Thanks as always for taking the time to look closely at this.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                   http://www.nwra.com

Re: [Plplot-devel] Comprehensive testing: Cygwin

[Arjen M. <Arj...@de...>]

Hi Alan,



Here is the result for Cygwin. A stupid mistake in my script threw everything away. I have corrected that.



I found one curious thing: the Python bindings are on in shared and nondynamic, but not in static. I have no idea why, because SWIG was found in all cases, but still CMake turns them off.



Regards,



Arjen



From: Arjen Markus [mailto:Arj...@de...]
Sent: Wednesday, April 22, 2015 2:18 PM
To: Alan W. Irwin
Cc: PLplot development list
Subject: Re: [Plplot-devel] Comprehensive testing: Cygwin


Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> You are welcome.  When you tailor that updated script (which automatically collects
> a list of the names and attributes of every file generated) with the --
> do_clean_as_you_go no option, I think that should finally give me enough
> information to help you with the figuring out part :-)
>
I installed SWIG and so got the Python bindings working, and saw good results along the way, unfortunately my script was not up to the deletion of the comprehensive_test_disposeable directory ;). The details have now been lost. I will have to redo this. Or better: review the script and set the computer to work.

Anyway, this new version will test a bit more parts of PLplot, but I could not find a Java development package under Cygwin, not in the Cygwin setup, that is. So for the moment it will only be Python that gets thrown into the mix as far as the language bindings are concerned. I will have to see if some of others are useable.

Regards,

Arjen






DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Incorrect pkg-config link flags with plplot 5.11.0

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

On 2015-04-22 22:44-0600 Orion Poplawski wrote:

> With plplot 5.10.0:
>
> # pkg-config plplotd --libs
> -lplplotd
>
> With plplot 5.11.0:
> -lplplot -lltdl -lm -lshp -lfreetype -lcsirocsa -lcsironn -lqhull -lqsastime
>
> # pkg-config plplot --libs
>
>
> This is wrong because the extra libraries are only necessary in the case of 
> static linking.

Hi Orion:

As always, thanks for your useful PLplot input from the Fedora
perspective.

Let me define some terminology here (used by CMake documentation) to
clarify my comments below. Non-transitive linking of an executable or
library occurs when you only specify the libraries to the linker are
needed to resolve symbols directly in the executable or library that
is being built. In contrast, transitive linking is when you mention
not only those libraries, but also all libraries that are required to
resolve all symbols throughout the hierachy of library links.

The CMake documentation states that in all cases transitive linking
should be used for the static case, and it is also safe to use that
for the shared case but for platforms that support it, non-transitive
linking can also be used for the shared library case.

To summarize what you have found in this terminology, our pkg-config results (which,
of course, have nothing to do with CMake other than we configure those
*.pc files with our CMake-based build system) follow those rules for the
static case, but for the shared case, 5.10.0 used non-transitive
linking while 5.11.0 used transitive linking (which apparently Fedora
complains about even though it is always safe to use transitive linking).

> To indicate this use Libs.private.  See also 
> http://people.freedesktop.org/~dbn/pkg-config-guide.html
>
> The attached patch fixes.  If some functions are referenced directly in the 
> public plplot headers then you would need to add them to Libs.

I just checked the two relevant *.pc files from 5.10.0 and 5.11.0, and
they are the same other than dropping the "d" suffix. So the change in
pkg-config result must not be due to something being done differently
by PLplot. Instead, my guess is Fedora is likely doing something
different now with pkg-config.  For example, perhaps before they
massaged pkg-config results but now they no longer do so more pkg-config
transitive linking issues are revealed?

That said, you are right (and actually the problem is likely more
fundamental and pervasive then you have stated).  I just checked, and
for 5.11.0 and many prior versions, the pkg-config file for a PLplot
library has been configured using the flag used to link to the library
as well as all flags necessary to link the library itself, i.e.,
transitive linking from the point of view of some app trying to link
to libplplot.  For example, both the 5.10.0 plplotd.pc file and the
5.11.0 plplot.pc file mention the link flags -lltdl -lm -lshp
-lfreetype -lcsirocsa -lcsironn -lqhull -lqsastime on the Libs: line
and do not mention Libs.private at all. Therefore, there has been a
long-term fundamental PLplot pkg-config issue for the shared linking
case for platforms that support non-transitive linking.

Another complication here is some platforms do not support
non-transitive linking for the shared library case.  For those, the
user must specify the -DNON_TRANSITIVE=OFF cmake option, and
that has to be propagated correctly to our configured pkg-config
files so they use non-transitive linking for the shared case
only when that is allowed by -DNON_TRANSITIVE=ON.

Anyhow, I am virtually positive your patch involving Libs.private:
will be part of the solution, but there is a lot to think about here
and check before coming up with what I hope is the definitive solution
for all the issues.  And I plan to do that early in this release cycle
after dealing with a bunch of other build-system issues that have
recently come to my attention (i.e., moving CMP0022 and CMP0023 from
OLD to NEW, moving CMP0026 from old to new, dealing with double
linking issues for tcl-related libraries when ENABLE_DYNDRIVERS=OFF,
and updating epa_build).

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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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-devel] Incorrect pkg-config link flags with plplot 5.11.0

[Orion P. <or...@co...>]

With plplot 5.10.0:

# pkg-config plplotd --libs
-lplplotd

With plplot 5.11.0:
-lplplot -lltdl -lm -lshp -lfreetype -lcsirocsa -lcsironn -lqhull 
-lqsastime

# pkg-config plplot --libs


This is wrong because the extra libraries are only necessary in the case 
of static linking.  To indicate this use Libs.private.  See also 
http://people.freedesktop.org/~dbn/pkg-config-guide.html

The attached patch fixes.  If some functions are referenced directly in 
the public plplot headers then you would need to add them to Libs.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  or...@co...
Boulder, CO 80301              http://www.cora.nwra.com

Re: [Plplot-devel] Comprehensive testing: Cygwin

[Arjen M. <Arj...@de...>]

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> You are welcome.  When you tailor that updated script (which automatically collects
> a list of the names and attributes of every file generated) with the --
> do_clean_as_you_go no option, I think that should finally give me enough
> information to help you with the figuring out part :-)
>
I installed SWIG and so got the Python bindings working, and saw good results along the way, unfortunately my script was not up to the deletion of the comprehensive_test_disposeable directory ;). The details have now been lost. I will have to redo this. Or better: review the script and set the computer to work.

Anyway, this new version will test a bit more parts of PLplot, but I could not find a Java development package under Cygwin, not in the Cygwin setup, that is. So for the moment it will only be Python that gets thrown into the mix as far as the language bindings are concerned. I will have to see if some of others are useable.

Regards,

Arjen







DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Commit id c44f636

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

Alan,

I'll add it to my list of things to look at.

Andrew

On Mon, Apr 20, 2015 at 05:48:09PM -0700, Alan Irwin wrote:
> Hi Andrew:
> 
> Commit id c44f636 makes a substantial hack to plparseopts so that the -debug
> option now works for any code (e.g., plInitDispatchTable) that is called
> by pllib_init.
> 
> The result passes substantial testing (valgrind, test_noninteractive,
> and test_interactive) on Linux, but you are much more familiar with
> the plparseopts code than I am so I would appreciate you looking at
> that hack to make sure I did not forget anything obvious.
> 
> 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); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); 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-devel] Comprehensive testing: MinGW/MSYS

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

On 2015-04-21 20:11-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Good detective work!  I agree you have completely pinned down the issue now, and
>> I look forward to your commit with the fix for plInBuildTree.
>>

> I am confident that the fix works for all our Windows environments,
as I use the WIN32_OR_CYGWIN variable to control the logic in
plInBuildTree. When I tried it earlier with a more restricted fix
(using the C macro WIN32), the whole comprehensive test ran fine. I do
not have time right now to repeat this, but testing an example
manually did what it was expected to do.

Hi Arjen:

Thanks for that fix.  Your confidence in the fix appears to be well
justified; on my older version of MinGW/MSYS and also on my Debian
stable platform, I confirmed manually testing one example with -debug
gave the expected results.

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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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-devel] memory leaks in wxWidgets driver?

[laurent B. <Lau...@un...>]

Hi,

I look fo memory leaks in my program using plplot 5.11. I am using vs 
2013 with Visual leak detector.
This tools finds two memory leaks in my plplot code in wxPlplotWindow.h 
at line 187(m_memory_dc) and line 195 (m_gcDc).
When I close wxPlplotwindow<> this two pointers are not deleted. May be 
I don't use good function to close wxPlplotwindow<>. Can you tell me how 
can I close it?

Thanks you for yours answers and for new version of plplot.

Re: [Plplot-devel] Comprehensive testing: MinGW/MSYS

[Arjen M. <Arj...@de...>]

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Good detective work!  I agree you have completely pinned down the issue now, and
> I look forward to your commit with the fix for plInBuildTree.
>
I am confident that the fix works for all our Windows environments, as I use the WIN32_OR_CYGWIN variable to control the logic in plInBuildTree. When I tried it earlier with a more restricted fix (using the C macro WIN32), the whole comprehensive test ran fine. I do not have time right now to repeat this, but testing an example manually did what it was expected to do.

I will run the comprehensive test tomorrow.

Regards,

Arjen





DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Comprehensive testing: MinGW/MSYS

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

On 2015-04-21 10:49-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
> After inspecting the code I suspected as much:
>
>
>
> markus@L01259 /d/plplot-svn/comprehensive_test_disposeable/shared/build_tree/examples/c
>
> $ ./x00c -debug
>
> plInBuildTree(): : current directory >d:\plplot-svn\comprehensive_test_disposeable\shared\build_tree\examples\c<
>
> plInBuildTree(): : build directory >D:/plplot-svn/comprehensive_test_disposeable/shared/build_tree<
>
> plInBuildTree(): : comparing respecting case

>
> plGetDrvDir: Trying to read env var PLPLOT_DRV_DIR
>
> plGetDrvDir: Will use drivers dir: d:/plplot-svn/comprehensive_test_disposeable/
>
> shared/install_tree/lib/plplot5.11.0/drivers
[...]
> There is a mixup of forward and backward slashes as well as a
difference in the case of the drive letter. Add to that that _MSV_VER
is not set and that therefore the comparison is done respecting the
case. Well, it should not be too hard to solve this. I will have a
closer look later today. At least we have pinned down the culprit.

Good detective work!  I agree you have completely pinned down the issue now, and I look
forward to your commit with the fix for plInBuildTree.

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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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-devel] Comprehensive testing: MinGW/MSYS

[Arjen M. <Arj...@de...>]

Hi Alan,



After inspecting the code I suspected as much:



markus@L01259 /d/plplot-svn/comprehensive_test_disposeable/shared/build_tree/examples/c

$ ./x00c -debug

plInBuildTree(): : current directory >d:\plplot-svn\comprehensive_test_disposeable\shared\build_tree\examples\c<

plInBuildTree(): : build directory >D:/plplot-svn/comprehensive_test_disposeable/shared/build_tree<

plInBuildTree(): : comparing respecting case

plGetDrvDir: Trying to read env var PLPLOT_DRV_DIR

plGetDrvDir: Will use drivers dir: d:/plplot-svn/comprehensive_test_disposeable/

shared/install_tree/lib/plplot5.11.0/drivers



*** PLPLOT ERROR, ABORTING OPERATION ***

plInitDispatchTable: Could not open drivers directory, aborting operation



Plotting Options:



Enter device number or keyword:

Invalid device: │½→w☻

markus@L01259 /d/plplot-svn/comprehensive_test_disposeable/shared/build_tree/examples/c

$



There is a mixup of forward and backward slashes as well as a difference in the case of the drive letter. Add to that that _MSV_VER is not set and that therefore the comparison is done respecting the case. Well, it should not be too hard to solve this. I will have a closer look later today. At least we have pinned down the culprit.



Regards,



Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Comprehensive testing: MinGW/MSYS

[Arjen M. <Arj...@de...>]

Hi Alan,


The output I got via the –debug option is at least somewhat revealing:

markus@L01259 /d/plplot-svn/comprehensive_test_disposeable
$ cd shared/build_tree/examples/c

markus@L01259 /d/plplot-svn/comprehensive_test_disposeable/shared/build_tree/exa
mples/c
$ ./x00c -debug
plGetDrvDir: Trying to read env var PLPLOT_DRV_DIR
plGetDrvDir: Will use drivers dir: d:/plplot-svn/comprehensive_test_disposeable/
shared/install_tree/lib/plplot5.11.0/drivers

*** PLPLOT ERROR, ABORTING OPERATION ***
plInitDispatchTable: Could not open drivers directory, aborting operation

Plotting Options:

Enter device number or keyword:
Invalid device: │½→w☻
markus@L01259 /d/plplot-svn/comprehensive_test_disposeable/shared/build_tree/exa
mples/c
$ echo $PLPLOT_DRV_DIR


markus@L01259 /d/plplot-svn/comprehensive_test_disposeable/shared/build_tree/exa
mples/c
$

Apparently plInBuildTree() is still returning 0 and therefore the install directory is being examined, even if that does not exist yet.

Well, this narrows it down quite a bit. I will add some debugging statements to that routine, to find out what is going on.

Regards,

Arjen

From: Arjen Markus [mailto:Arj...@de...]


I am getting some inconsistent results. I first ran the tests with the extra environment variables all set and the –do_clean_as_you_go off and then I was able to run the examples that were created _without any additional parameters_ in a different MSYS shell window (well, the PATH needed to be extended).

So I was enthousiastic, dropped the additional parameters and dropped –do_clean_as_you_go. The examples that were

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Comprehensive testing: MinGW/MSYS

[Arjen M. <Arj...@de...>]

Hi Alan, Greg,




> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> Note as soon as Arjen reports comprehensive testing success with MinGW/MSYS
> without having to take brute-force measures like setting
> PLPLOT* environment variables to get around the above "detection-of-build-tree
> test" bug, then I would encourage you to try comprehensive testing again on that
> platform (as well as
> MinGW-w64/MSYS2) using a tailored version of the "comprehensively test, and
> collect" script that will be included with his test report tarball.
>
I am getting some inconsistent results. I first ran the tests with the extra environment variables all set and the -do_clean_as_you_go off and then I was able to run the examples that were created _without any additional parameters_ in a different MSYS shell window (well, the PATH needed to be extended).

So I was enthousiastic, dropped the additional parameters and dropped -do_clean_as_you_go. The examples that were built under these conditions will not run! I am investigating the reasons for this.

Regards,

Arjen



DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Comprehensive testing: MinGW/MSYS

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

On 2015-04-20 21:18-0700 Greg Jung wrote:

> Alan,
>   Since these strings  that are kept in files, that need to be
> associated with each possible driver,
> do not change over the years, why maintain a separate location? Why
> not just compile those strings
> into the body of plplot.obj?  The increase of data size will probably
> be balanced by the decrease in support code.

Hi Greg:

Those <driver>.driver_info files are not static.  They are configured
instead (actually in two different ways that are compared against each
other to check for internal consistency) depending on choices made by
the user and resources available on the platform.  I guess it should
be possible to configure source code with these data, but I am pretty
sure that would be an attempt to replace one configuration complexity
with another so I don't think that effort would be worth the trouble.

Note I am pretty sure Arjen's current MinGW/MSYS issues (and probably
yours also when you tried to comprehensively test that platform) were
due to a failure (for recent versions of classical MinGW/MSYS) to
detect that the examples were being run in the build tree as opposed
to the install tree.  So the PLplot library that was built in the
build tree was looking in the wrong install-tree locations for
build-tree data (which doesn't work too well if nothing is installed
yet).  So this bug generated a lot of different testing issues of
which finding the build-tree version of the <driver>.driver_info files
was just one.  And assuming I have fixed the "detection-of-build-tree
test" bug, then my hope is most/all of those nagging Windows issues 
with finding resources that PLplot needs will just smoothly disappear.

Note as soon as Arjen reports comprehensive testing success with
MinGW/MSYS without having to take brute-force measures like setting
PLPLOT* environment variables to get around the above
"detection-of-build-tree test" bug, then I would encourage you to try
comprehensive testing again on that platform (as well as
MinGW-w64/MSYS2) using a tailored version of the "comprehensively
test, and collect" script that will be included with his test report
tarball.

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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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-devel] Comprehensive testing: MinGW/MSYS

[Greg J. <gv...@gm...>]

Alan,
   Since these strings  that are kept in files, that need to be
associated with each possible driver,
do not change over the years, why maintain a separate location? Why
not just compile those strings
into the body of plplot.obj?  The increase of data size will probably
be balanced by the decrease in support code.

On Mon, Apr 20, 2015 at 7:12 PM, Alan W. Irwin
<ir...@be...> wrote:
> On 2015-04-20 13:27-0700 Alan W. Irwin wrote:
>
>> On 2015-04-20 12:55-0700 Alan W. Irwin wrote:
>>
>>> Furthermore -debug works fine for me on MinGW/MSYS/Wine, but the only
>>> extra output from it comes after the device is selected from the list
>>> above. So to debug further you will have to (locally) add informative
>>> pldebug calls to the code near where the error message above
>>> "plInitDispatchTable: Could not open drivers directory, aborting
>>> operation" is being generated.
>>>
>>> I look forward to seeing those results from you.
>>
>> Hi Arjen:
>>
>> Actually, I take that "works fine for me" back.  If you look at the
>> code, the error message is generated after a call to plGetDrvDir
>> which has pldebug() calls in it.  Those work on Linux.
>>
>> Here is what happens on Linux when the the ps device has not been built
>> (to cut down on the debug output).
>>
>> software@raven> examples/c/x00c -debug -dev psc -o test.psc
>> plLoadDriver: Device not loaded!
>> plLoadDriver: tag=psc, drvidx=0
>> plGetDrvDir: Using /home/software/plplot/HEAD/build_dir/drivers as the
>> driver directory.
>> plLoadDriver: Trying to load ps on
>> /home/software/plplot/HEAD/build_dir/drivers/ps
>> plLoadDriver: lt_dlopenext failed because of the following reason:
>> file not found
>> Unable to load driver: ps.
>>
>> *** PLPLOT ERROR, IMMEDIATE EXIT ***
>> Unable to load driver
>> Program aborted
>>
>> So there is a message from plGetDrvDir above on exactly what drivers
>> directory is being used in the build tree (which gets the build-tree
>> version of that directory because of the plInBuildTree() result).
>>
>> On MinGW/MSYS/Wine here is the equivalent result (again without the
>> ps.dll device available to make output short).
>>
>> bash.exe-3.1$ examples/c/x00c -debug -dev psc -o test.psc
>> plLoadDriver: Device not loaded!
>> plLoadDriver: tag=psc, drvidx=0
>> plLoadDriver: Trying to load ps on ps
>> plLoadDriver: lt_dlopenext failed because of the following reason:
>> No error information
>> Unable to load driver: ps.
>>
>> *** PLPLOT ERROR, IMMEDIATE EXIT ***
>> Unable to load driver
>> Program aborted
>>
>> So in my particular MinGW/MSYS/Wine case I get this very strange
>> result that either (1) there is no call to plGetDrvDir at all or (2)
>> somehow pldebug is not working for just that particular routine.
>>
>> So I now find myself in the position of having to debug the -debug
>> option on this platform, and I hope you try that as well.
>>
>> And if you figure out that last sentence, it means you are truly a PLplot
>> guru.  :-)
>
> Hi Arjen:
>
> To follow up, the above difference is actually expected because
> plGetDrvDir is not called in that context on Windows platforms.
>
> However, that function is also called (both on Linux and Windows) in a
> different context (from plInitDispatchTable) where -debug was silent
> for all platforms. I have now corrected that silence (commit id
> c44f636).
>
> Here is the new -debug result on MinGW/MSYS/Wine (still without
> ps.dll built to shorten the messages).
>
> bash.exe-3.1$ examples/c/x00c -debug -dev psc -o test.psc 2>&1 |less
> plGetDrvDir: Using Z:/home/wine/newstart/build_script/build_dir-1.6.1/epa_build/Source/comprehensive_test_disposeable/shared/build_tree/drivers as the driver directory.
> plInitDispatchTable: Scanning dyndrivers dir
> plInitDispatchTable: Consider file .
> plInitDispatchTable: Consider file ..
> plInitDispatchTable: Consider file ps.driver_info
> plInitDispatchTable: Opened driver info file ps.driver_info
> plInitDispatchTable: Consider file xfig.driver_info
> plInitDispatchTable: Opened driver info file xfig.driver_info
> plInitDispatchTable: Consider file pdf.driver_info
> plInitDispatchTable: Opened driver info file pdf.driver_info
> plInitDispatchTable: Consider file Makefile
> plInitDispatchTable: Consider file null.driver_info
> plInitDispatchTable: Opened driver info file null.driver_info
> plInitDispatchTable: Consider file CMakeFiles
> plInitDispatchTable: Consider file mem.driver_info
> plInitDispatchTable: Opened driver info file mem.driver_info
> plInitDispatchTable: Consider file svg.driver_info
> plInitDispatchTable: Opened driver info file svg.driver_info
> plInitDispatchTable: Consider file wingcc.driver_info
> plInitDispatchTable: Opened driver info file wingcc.driver_info
> plInitDispatchTable: Consider file ntk.driver_info
> plInitDispatchTable: Opened driver info file ntk.driver_info
> plInitDispatchTable: Consider file cmake_install.cmake
> plInitDispatchTable: Consider file CTestTestfile.cmake
> plLoadDriver: Device not loaded!
> plLoadDriver: tag=psc, drvidx=0
> plLoadDriver: Trying to load ps on ps
> plLoadDriver: lt_dlopenext failed because of the following reason:
> No error information
> Unable to load driver: ps.
>
> *** PLPLOT ERROR, IMMEDIATE EXIT ***
> Unable to load driver
> Program aborted
>
> So obviously in this case the drivers directory is being found properly
> by plGetDrvDir called from plInitDispatchTable.
>
> If you look at the plGetDrvDir code in src/plcore.c, the only
> case where  PLPLOT_DRV_DIR is important is if the build-tree
> detection fails.
>
> So basically the difference between us is
>
> plInBuildTree() == 1
>
> for my platform but not for yours which you can confirm by
> doing the above individual test and looking at
> the form of the first message that comes out (which is
> different if plInBuildTree() == 1 is not detected).
>
> And if the build-tree detection is failing for you that screws up lots
> of other build-tree stuff, and jibes with you having to brute-force
> the problem by setting other PLPLOT-related environment variables as
> well.
>
> It turns out the plInBuildTree logic depends closely on whether the
> directory separator is a "/" or a "\", and I suspect what has happened
> is my older version of MSYS uses "\" while your more modern version
> uses "/" in this context.
>
> Accordingly, I have changed the plInBuildTree code to work for either
> separator on Windows (commit ID 8ffab0b).  That change gave the same
> good results as above for me, and I hope it will also solve _all_ your
> brute force issues (i.e., reliance on PLPLOT* environment variables
> can be dropped) on your more modern MinGW/MSYS.
>
> If that change works for you with individual tests, then please follow
> up with the corresponding comprehensive test with no PLPLOT-*
> environment variables set.  And if that is a success please
> repeat with
>
> --do_clean_as_you_go no
>
> dropped (since there is no need to chew up your disk space anymore)
>
> and you also should drop
>
> --do_ctest no
> --do_test_interactive no
>
> to make the test as strong as possible (outside using the epa_build
> variation of this test which strengthens it even more by building some
> of the soft dependencies for PLplot such as pkg-config, Tcl/Tk, qhull,
> and shapelib).
>
> If you have any failures along the way, the usual corresponding
> tarball is requested.  But if every test is a success, then you are
> done with MinGW/MSYS testing (YEAH!), and I only need that tarball for the
> last (strongest) test so I can post those good results on our wiki as
> a benchmark to help guard against future regressions introduced in
> this release cycle.
>
> I hope you find these new developments as interesting as I do.  I have
> been frustrated for years by PLplot just not working very well on the
> various Windows platforms, and it feels really good to be able to
> tackle some of these issues now thanks to your willingness to run
> comprehensive tests on various Windows platform and the vastly
> improved automatic data collection for your comprehensive test results
> that now exists.
>
> 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); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); 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
> __________________________
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Comprehensive testing: MinGW/MSYS

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

On 2015-04-20 13:27-0700 Alan W. Irwin wrote:

> On 2015-04-20 12:55-0700 Alan W. Irwin wrote:
>
>> Furthermore -debug works fine for me on MinGW/MSYS/Wine, but the only
>> extra output from it comes after the device is selected from the list
>> above. So to debug further you will have to (locally) add informative
>> pldebug calls to the code near where the error message above
>> "plInitDispatchTable: Could not open drivers directory, aborting
>> operation" is being generated.
>>
>> I look forward to seeing those results from you.
>
> Hi Arjen:
>
> Actually, I take that "works fine for me" back.  If you look at the
> code, the error message is generated after a call to plGetDrvDir
> which has pldebug() calls in it.  Those work on Linux.
>
> Here is what happens on Linux when the the ps device has not been built
> (to cut down on the debug output).
>
> software@raven> examples/c/x00c -debug -dev psc -o test.psc
> plLoadDriver: Device not loaded!
> plLoadDriver: tag=psc, drvidx=0
> plGetDrvDir: Using /home/software/plplot/HEAD/build_dir/drivers as the
> driver directory.
> plLoadDriver: Trying to load ps on
> /home/software/plplot/HEAD/build_dir/drivers/ps
> plLoadDriver: lt_dlopenext failed because of the following reason:
> file not found
> Unable to load driver: ps.
>
> *** PLPLOT ERROR, IMMEDIATE EXIT ***
> Unable to load driver
> Program aborted
>
> So there is a message from plGetDrvDir above on exactly what drivers
> directory is being used in the build tree (which gets the build-tree
> version of that directory because of the plInBuildTree() result).
>
> On MinGW/MSYS/Wine here is the equivalent result (again without the
> ps.dll device available to make output short).
>
> bash.exe-3.1$ examples/c/x00c -debug -dev psc -o test.psc
> plLoadDriver: Device not loaded!
> plLoadDriver: tag=psc, drvidx=0
> plLoadDriver: Trying to load ps on ps
> plLoadDriver: lt_dlopenext failed because of the following reason:
> No error information
> Unable to load driver: ps.
>
> *** PLPLOT ERROR, IMMEDIATE EXIT ***
> Unable to load driver
> Program aborted
>
> So in my particular MinGW/MSYS/Wine case I get this very strange
> result that either (1) there is no call to plGetDrvDir at all or (2)
> somehow pldebug is not working for just that particular routine.
>
> So I now find myself in the position of having to debug the -debug
> option on this platform, and I hope you try that as well.
>
> And if you figure out that last sentence, it means you are truly a PLplot
> guru.  :-)

Hi Arjen:

To follow up, the above difference is actually expected because
plGetDrvDir is not called in that context on Windows platforms.

However, that function is also called (both on Linux and Windows) in a
different context (from plInitDispatchTable) where -debug was silent
for all platforms. I have now corrected that silence (commit id
c44f636).

Here is the new -debug result on MinGW/MSYS/Wine (still without
ps.dll built to shorten the messages).

bash.exe-3.1$ examples/c/x00c -debug -dev psc -o test.psc 2>&1 |less
plGetDrvDir: Using Z:/home/wine/newstart/build_script/build_dir-1.6.1/epa_build/Source/comprehensive_test_disposeable/shared/build_tree/drivers as the driver directory.
plInitDispatchTable: Scanning dyndrivers dir
plInitDispatchTable: Consider file .
plInitDispatchTable: Consider file ..
plInitDispatchTable: Consider file ps.driver_info
plInitDispatchTable: Opened driver info file ps.driver_info
plInitDispatchTable: Consider file xfig.driver_info
plInitDispatchTable: Opened driver info file xfig.driver_info
plInitDispatchTable: Consider file pdf.driver_info
plInitDispatchTable: Opened driver info file pdf.driver_info
plInitDispatchTable: Consider file Makefile
plInitDispatchTable: Consider file null.driver_info
plInitDispatchTable: Opened driver info file null.driver_info
plInitDispatchTable: Consider file CMakeFiles
plInitDispatchTable: Consider file mem.driver_info
plInitDispatchTable: Opened driver info file mem.driver_info
plInitDispatchTable: Consider file svg.driver_info
plInitDispatchTable: Opened driver info file svg.driver_info
plInitDispatchTable: Consider file wingcc.driver_info
plInitDispatchTable: Opened driver info file wingcc.driver_info
plInitDispatchTable: Consider file ntk.driver_info
plInitDispatchTable: Opened driver info file ntk.driver_info
plInitDispatchTable: Consider file cmake_install.cmake
plInitDispatchTable: Consider file CTestTestfile.cmake
plLoadDriver: Device not loaded!
plLoadDriver: tag=psc, drvidx=0
plLoadDriver: Trying to load ps on ps 
plLoadDriver: lt_dlopenext failed because of the following reason:
No error information
Unable to load driver: ps.

*** PLPLOT ERROR, IMMEDIATE EXIT ***
Unable to load driver
Program aborted

So obviously in this case the drivers directory is being found properly
by plGetDrvDir called from plInitDispatchTable.

If you look at the plGetDrvDir code in src/plcore.c, the only
case where  PLPLOT_DRV_DIR is important is if the build-tree
detection fails.

So basically the difference between us is

plInBuildTree() == 1

for my platform but not for yours which you can confirm by
doing the above individual test and looking at
the form of the first message that comes out (which is
different if plInBuildTree() == 1 is not detected).

And if the build-tree detection is failing for you that screws up lots
of other build-tree stuff, and jibes with you having to brute-force
the problem by setting other PLPLOT-related environment variables as
well.

It turns out the plInBuildTree logic depends closely on whether the
directory separator is a "/" or a "\", and I suspect what has happened
is my older version of MSYS uses "\" while your more modern version
uses "/" in this context.

Accordingly, I have changed the plInBuildTree code to work for either
separator on Windows (commit ID 8ffab0b).  That change gave the same
good results as above for me, and I hope it will also solve _all_ your
brute force issues (i.e., reliance on PLPLOT* environment variables
can be dropped) on your more modern MinGW/MSYS.

If that change works for you with individual tests, then please follow
up with the corresponding comprehensive test with no PLPLOT-*
environment variables set.  And if that is a success please
repeat with

--do_clean_as_you_go no

dropped (since there is no need to chew up your disk space anymore)

and you also should drop

--do_ctest no
--do_test_interactive no

to make the test as strong as possible (outside using the epa_build
variation of this test which strengthens it even more by building some
of the soft dependencies for PLplot such as pkg-config, Tcl/Tk, qhull,
and shapelib).

If you have any failures along the way, the usual corresponding
tarball is requested.  But if every test is a success, then you are
done with MinGW/MSYS testing (YEAH!), and I only need that tarball for the
last (strongest) test so I can post those good results on our wiki as
a benchmark to help guard against future regressions introduced in
this release cycle.

I hope you find these new developments as interesting as I do.  I have
been frustrated for years by PLplot just not working very well on the
various Windows platforms, and it feels really good to be able to
tackle some of these issues now thanks to your willingness to run
comprehensive tests on various Windows platform and the vastly
improved automatic data collection for your comprehensive test results
that now exists.

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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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-devel] Commit id c44f636

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

Hi Andrew:

Commit id c44f636 makes a substantial hack to plparseopts so that the -debug
option now works for any code (e.g., plInitDispatchTable) that is called
by pllib_init.

The result passes substantial testing (valgrind, test_noninteractive,
and test_interactive) on Linux, but you are much more familiar with
the plparseopts code than I am so I would appreciate you looking at
that hack to make sure I did not forget anything obvious.

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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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
__________________________