plplot-general — PLplot user discussion group

Re: [Plplot-general] PLPLOT-5.14.0: building cairo.dll fails (Windows 10)

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

Hi Alan,

-----Original Message-----
From: Alan W. Irwin <Ala...@gm...>
Sent: 04 January 2019 09:00


@Arjen: you will likely also be affected by the same bug and have to do the same fix when you update your own MinGW-w64/MSYS2.

I will keep this in mind - unfortunately a hiccup in the updating/upgrading procedure I just tried (pacman -Syuu) has caused the removal of the pacman executable, so I will have to reinstall the whole of MinGW-w64/MSYS2 before I can even run into the problem. Oh well, such is life.

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-general] PLPLOT-5.14.0: building cairo.dll fails (Windows 10)

[Alan W. I. <Ala...@gm...>]

On 2019-01-04 11:47+0530 Tom Schoonjans wrote:

> Hi all,
>
>
> I ran into the same problem a couple of weeks ago. It is in fact a bug in pango 1.43.0 which uses meson as buildsystem instead of autotools, and the pkg-config issue was introduced in the transition.
>
> I reported this as a bug <https://gitlab.gnome.org/GNOME/pango/merge_requests/22#note_390137> and submitted a patch <https://gitlab.gnome.org/GNOME/pango/merge_requests/38>, which is now in master and should end up in 1.44 (or possibly in 1.43.1 if this ever gets released).
>
> In the meantime, the problem can be fixed by executing:
>
> 	echo "Requires: gobject-2.0" >> /mingw64/lib/pkgconfig/pango.pc
>
> followed by building plplot… The cairo backend should build fine then.
>

Thanks, Tom, for that really helpful comment about what appears to be a
widespread issue with pango 1.43.0.  That's a heavily used free
library.  So let's hope the upstream pango developers quickly release
1.43.1 with your fix and that quickly propagates to free software
distributions for Linux (thousands of them), Mac OS X (fink, macports,
and homebrew), and Windows (Cygwin and MinGW-w64/MSYS2).

@Günter:

So to summarize, it looks like my recent tests on Debian Testing have
been fine because I have installed cairo 1.42.3, and that platform has
not (yet) got around to packaging cairo-1.43.0.  Arjen's test was also
a success because he has cairo 1.42.1 currently installed (and has not
yet updated his system), but your recent test failed because you did
do such an update which exposed you to the bad pango 1.43.0 version.
So hopefully Tom's above echo command will sort out the issue for you
until upstream developers fix the issue, and that fix propagates to
MinGW-w64/MSYS2.

At the same time, I also stand by my advice to drop "MinGW Makefiles"
and mingw32-make and use the "Unix Makefiles" or "MSYS Makefiles"
generators and bash and make instead simply because if you ever run
into PLplot trouble with the platform, the very much enhanced test
capability (via bash scripts) you have access to with the latter
method can be quite useful, e.g., the report tarball that can
be generated for that case makes it much easier to
understand your bug reports.

@Arjen: you will likely also be affected by the same bug and have to do the same fix
when you update your own MinGW-w64/MSYS2.

And I will likely be affected by the same bug if Debian Testing starts packaging
pango 1.43.0.

Alan
__________________________
Alan W. Irwin

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-general] PLPLOT-5.14.0: building cairo.dll fails (Windows 10)

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

Hi Alan, Günter,

I use the Unix Makefiles generator as that seems to work best on the given platform. I will have to check your report against what I have found. Will get back to you on this.

Regards,

Arjen

-----Original Message-----
From: Alan W. Irwin <Ala...@gm...>
Sent: 04 January 2019 02:00
To: plplot_general <plp...@li...>; Günter Kanisch <Gue...@ha...>
Subject: Re: [Plplot-general] PLPLOT-5.14.0: building cairo.dll fails (Windows 10)

Hi Günter:

I have put my reply to your message on the plplot-general mailing list since your remarks and mine will be of interest to subscribers there.
Therefore, if you have not already subscribed to that list you should do so now since that is where such support requests are normally addressed.

More below in context.

On 2019-01-03 19:29+0100 Günter Kanisch wrote:

> Dear Alan,
>
> After a longer time having worked with the 32-bit version of plplot
> under Windows, I want to migrate now to the 64-bit executable of my
> Fortran/GTK/plplot program.  The fortran mathematics and the GTK gui
> are already running as an 64-bit executable. However, building now
> plplot-5.14.0 fails with linking the cairo.dll (in the path ..
> drivers/CMakeFiles/cairo.dir) resulting in two error messages: unknown
> reference to 'g_object_unref' .
>
> I am working with MSYS2 (installed under d:\msys64\mingw64 under
> Windows 10); it contains the 64-bitcompilers and GTK and so on, but also mingw32-make.exe.
>
> I tried it for some days now - and could not solve the problem. At
> least, its seems that cmake finds all the correct 64-bit versions of exe and dll files.
>
> I attach a text file containing the console output of the cmake and
> thereafter of the mingw32-make command(s), executed by a small bacth file.
> The cairo-related errors appears at the end of the file. I cannot
> exclude that the two commands (cmake and then mingw32-make) which I
> used are not sufficient for a complete build.
>
> Can you recommend some changes in my build steps which I could try then here?

I have no direct knowledge of the MinGW-w64/MSYS2 platform, but I keep in close touch with the PLplot developer Arjen Markus (who will be reading this on the plplot-general mailing list) who has had great recent success with the 64-bit MinGW-w64/MSYS2 platform.  That is, you will see at <https://sourceforge.net/p/plplot/wiki/Testing_Reports/>
that Arjen has achieved almost perfect comprehensive test results with this platform in October.  So there is excellent hope you will be able to achieve that near-perfection as well with PLplot on this platform.
:-)

I have just looked at the report from that test (which he shared with me), and it appears his pango, and cairo CMake find results were similar to the ones you have attached, i.e.,

irwin@merlin> grep -Ei 'cairo|pango' Arjen.Markus/20181026/MSYS2/shared/noninteractive/output_tree/cmake.out
-- Checking for module 'pango'
--   Found pango, version 1.42.1
-- Checking for module 'pangoft2'
--   Found pangoft2, version 1.42.1
-- Checking for module 'pangocairo'
--   Found pangocairo, version 1.42.1
-- WARNING: X windows not found. Setting xcairo driver to OFF.
-- Checking for modules 'lasi;pango;pangoft2'
-- WARNING: pango, pangoft2, or lasi not found with pkg-config.
-- WARNING: ENABLE_ocaml is OFF so disabling Plcairo module and lablgtk2 support
-- Determine compile and link flags for ext-cairo-test
-- Checking for module 'cairo'
--   Found cairo, version 1.15.12
DRIVERS_LIST: cairo;qt;mem;ntk;null;pdf;ps;svg;wingcc;xfig
DEVICES_LIST: memcairo;extcairo;pdfcairo;pngcairo;pscairo;epscairo;svgcairo;wincairo;pdfqt;qtwidget;bmpqt;jpgqt;pngqt;ppmqt;tiffqt;extqt;memqt;svgqt;mem;ntk;null;pdf;ps;psc;svg;wingcc;xfig

irwin@merlin> grep -Ei 'cairo|pango' Günter.Kanisch/20190103/MSYS2/text9.txt
-- Checking for module 'pango'
--   Found pango, version 1.43.0
-- Checking for module 'pangoft2'
--   Found pangoft2, version 1.43.0
-- Checking for module 'pangocairo'
--   Found pangocairo, version 1.43.0
-- WARNING: X windows not found. Setting xcairo driver to OFF.
-- Checking for modules 'lasi;pango;pangoft2'
-- WARNING: pango, pangoft2, or lasi not found with pkg-config.
-- WARNING: ENABLE_ocaml is OFF so disabling Plcairo module and lablgtk2 support
-- Determine compile and link flags for ext-cairo-test
-- Checking for module 'cairo'
--   Found cairo, version 1.16.0
DRIVERS_LIST: cairo;mem;ntk;null;pdf;ps;svg;wingcc;xfig
DEVICES_LIST: memcairo;extcairo;pdfcairo;pngcairo;pscairo;epscairo;svgcairo;wincairo;mem;ntk;null;pdf;ps;psc;svg;wingcc;xfig
[...] (I have excluded build results to make yours comparable with Arjen's cmake results.)

So it appears you have found slightly newever versions of the same pango and cairo libraries found by Arjen so I don't see any issues with your configuration.

@Arjen: will you double check that please?

@Günter

However, a possible issue is you have used the "MinGW-Makefiles"
generator.  In theory, that is supposed to work correctly on the
MinGW-w64/MSYS2 platform with mingw32-make, but Arjen has not yet tried testing that variant, and it is possible there is some cairo configuration issue or even "MinGW-Makefiles" cmake generator issue for that case which is not an issue if you use the "Unix Makefiles"
generator with make (that Arjen used for his test as you can see from the wiki test report).

Furthermore, here are the differences in the actual cairo build between Arjen and you.

Arjen's build result:

[ 13%] Building C object drivers/CMakeFiles/cairo.dir/cairo.c.obj
cd D:/plplot-svn/comprehensive_test_disposeable/shared/noninteractive/build_tree/drivers && D:/msys64-new/mingw64/bin/cc.exe -DPLPLOT_HAVE_CONFIG_H -DUSINGDLL -Dcairo_EXPORTS @CMakeFiles/cairo.dir/includes_C.rsp  -mms-bitfields -ID:/msys64-new/mingw64/include/pango-1.0 -ID:/msys64-new/mingw64/include/fribidi -ID:/msys64-new/mingw64/include/cairo -ID:/msys64-new/mingw64/include/pixman-1 -ID:/msys64-new/mingw64/include -ID:/msys64-new/mingw64/include/freetype2 -ID:/msys64-new/mingw64/include -ID:/msys64-new/mingw64/include/harfbuzz -ID:/msys64-new/mingw64/include/glib-2.0 -ID:/msys64-new/mingw64/lib/glib-2.0/include -ID:/msys64-new/mingw64/include -ID:/msys64-new/mingw64/include/libpng16 -ID:/msys64-new/mingw64/include -o CMakeFiles/cairo.dir/cairo.c.obj   -c D:/plplot-svn/plplot-git/drivers/cairo.c
[ 13%] Linking C shared module ../dll/cairo.dll cd D:/plplot-svn/comprehensive_test_disposeable/shared/noninteractive/build_tree/drivers && D:/msys64-new/mingw64/bin/cmake.exe -E remove -f CMakeFiles/cairo.dir/objects.a cd D:/plplot-svn/comprehensive_test_disposeable/shared/noninteractive/build_tree/drivers && D:/msys64-new/mingw64/bin/ar.exe cr CMakeFiles/cairo.dir/objects.a @CMakeFiles/cairo.dir/objects1.rsp
cd D:/plplot-svn/comprehensive_test_disposeable/shared/noninteractive/build_tree/drivers && D:/msys64-new/mingw64/bin/cc.exe    -shared -o ../dll/cairo.dll -Wl,--major-image-version,0,--minor-image-version,0 -Wl,--whole-archive CMakeFiles/cairo.dir/objects.a -Wl,--no-whole-archive @CMakeFiles/cairo.dir/linklibs.rsp
make[3]: Leaving directory '/d/plplot-svn/comprehensive_test_disposeable/shared/noninteractive/build_tree'
[ 13%] Built target cairo


Your result (from the attached file):

[ 42%] Building C object drivers/CMakeFiles/cairo.dir/cairo.c.obj
cd /d D:\plplot-5.14.0\buildmingw64\drivers && D:\msys64\mingw64\bin\gcc.exe -DPLPLOT_HAVE_CONFIG_H -DUSINGDLL -Dcairo_EXPORTS @CMakeFiles/cairo.dir/includes_C.rsp  -mms-bitfields -Id:/msys64/mingw64/include/pango-1.0 -Id:/msys64/mingw64/include/fribidi -Id:/msys64/mingw64/include -Id:/msys64/mingw64/include/cairo -Id:/msys64/mingw64/include -Id:/msys64/mingw64/lib/libffi-3.2.1/include -Id:/msys64/mingw64/include/pixman-1 -Id:/msys64/mingw64/include -Id:/msys64/mingw64/include/freetype2 -Id:/msys64/mingw64/include -Id:/msys64/mingw64/include/harfbuzz -Id:/msys64/mingw64/include/glib-2.0 -Id:/msys64/mingw64/lib/glib-2.0/include -Id:/msys64/mingw64/include -Id:/msys64/mingw64/include/libpng16 -Id:/msys64/mingw64/include -o CMakeFiles\cairo.dir\cairo.c.obj   -c D:\plplot-5.14.0\drivers\cairo.c
[ 42%] Linking C shared module ..\dll\cairo.dll cd /d D:\plplot-5.14.0\buildmingw64\drivers && D:\msys64\mingw64\bin\cmake.exe -E cmake_link_script CMakeFiles\cairo.dir\link.txt --verbose=1 D:\msys64\mingw64\bin\cmake.exe -E remove -f CMakeFiles\cairo.dir/objects.a D:\msys64\mingw64\bin\ar.exe cr CMakeFiles\cairo.dir/objects.a @CMakeFiles\cairo.dir\objects1.rsp
D:\msys64\mingw64\bin\gcc.exe    -shared -o ..\dll\cairo.dll -Wl,--major-image-version,0,--minor-image-version,0 -Wl,--whole-archive CMakeFiles\cairo.dir/objects.a -Wl,--no-whole-archive @CMakeFiles\cairo.dir\linklibs.rsp
CMakeFiles\cairo.dir/objects.a(cairo.c.obj):cairo.c:(.text+0x1279): undefined reference to `g_object_unref'
CMakeFiles\cairo.dir/objects.a(cairo.c.obj):cairo.c:(.text+0x16f4): undefined reference to `g_object_unref'
collect2.exe: error: ld returned 1 exit status
mingw32-make[2]: *** [drivers\CMakeFiles\cairo.dir\build.make:97: dll/cairo.dll] Error 1
mingw32-make[2]: Leaving directory 'D:/plplot-5.14.0/buildmingw64'
mingw32-make[1]: *** [CMakeFiles\Makefile2:1733: drivers/CMakeFiles/cairo.dir/all] Error 2
mingw32-make[1]: Leaving directory 'D:/plplot-5.14.0/buildmingw64'
mingw32-make: *** [Makefile:154: all] Error 2

So it appears your link step for our cairo device driver is quite different from Arjen's.  It's possible these differences are due to Arjen still using Windows 7 for his last comprehensive test while you are using Windows 10.  But ideally CMake should be able to adjust for those differences.

Anyhow, to get closer to the combination that works well for Arjen, I suggest you install the msys/bash and msys/make packages (which includes the Unix-style "make" command) from the msys archive and try the "Unix Makefiles" generator instead with make (run from a bash command line).

Note, if you want to go back to the "MinGW Makefiles" approach after trying "Unix Makefiles" (or the very similar "MSYS Makefiles") then you will have to remove the msys/bash package which is incompatible with the "MinGW Makefiles" generator without a hack I know (remove the sh.exe copy of bash.exe) to work around that issue.

By the way, if you still continue to have cairo linking problems when you switch to "Unix Makefiles" generator + msys make, I hope you will be willing to send this list a report tarball containing everything we need to know.  This is only possible on platforms with bash which is another reason for you to install msys/make and msys/bash.

On such platforms the way you create that tarball is simply to run

scripts/comprehensive_testing.sh

For a lot of important details about that script please look at <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/>

> By the way: I observed that I do not know the libplplotfortran.dll.
> Does it replace one/some other dlls I have used previously?

libplplotfortran contains our modern Fortran binding for PLplot so it is essential for you with PLplot-5.14.0 (and also at least one previous version).  So I infer you are trying to upgrade from a fairly old version of PLplot.  I highly encourage that step because of all the bug fixing and new features available with modern PLplot, but it does involve some "upgrade pain" for you.  But I hope such discussions as these will ease that pain for you.

> Thank you very much in advance - and all the best for a successful new year!

Thanks, and you too.

Alan
__________________________
Alan W. Irwin

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
__________________________
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-general] PLPLOT-5.14.0: building cairo.dll fails (Windows 10)

[Tom S. <tom...@me...>]

Hi all,


I ran into the same problem a couple of weeks ago. It is in fact a bug in pango 1.43.0 which uses meson as buildsystem instead of autotools, and the pkg-config issue was introduced in the transition.

I reported this as a bug <https://gitlab.gnome.org/GNOME/pango/merge_requests/22#note_390137> and submitted a patch <https://gitlab.gnome.org/GNOME/pango/merge_requests/38>, which is now in master and should end up in 1.44 (or possibly in 1.43.1 if this ever gets released).

In the meantime, the problem can be fixed by executing:

	echo "Requires: gobject-2.0" >> /mingw64/lib/pkgconfig/pango.pc

followed by building plplot… The cairo backend should build fine then.

Best regards,

Tom

> On 4 Jan 2019, at 06:30, Alan W. Irwin <Ala...@gm...> wrote:
> 
> Hi Günter:
> 
> I have put my reply to your message on the plplot-general mailing list
> since your remarks and mine will be of interest to subscribers there.
> Therefore, if you have not already subscribed to that list you should do so
> now since that is where such support requests are normally addressed.
> 
> More below in context.
> 
> On 2019-01-03 19:29+0100 Günter Kanisch wrote:
> 
>> Dear Alan,
>> 
>> After a longer time having worked with the 32-bit version of plplot under Windows, I want to migrate now to the 64-bit executable of my Fortran/GTK/plplot program.  The fortran mathematics and the GTK gui are already running as an 64-bit executable. However, building now plplot-5.14.0 fails with linking the cairo.dll (in the path .. drivers/CMakeFiles/cairo.dir) resulting in two error messages: unknown reference to 'g_object_unref' .
>> 
>> I am working with MSYS2 (installed under d:\msys64\mingw64 under Windows 10); it contains the 64-bitcompilers and GTK and so on, but also mingw32-make.exe.
>> 
>> I tried it for some days now - and could not solve the problem. At least, its seems that cmake finds all the correct 64-bit versions of exe and dll files.
>> 
>> I attach a text file containing the console output of the cmake and thereafter of the mingw32-make command(s), executed by a small bacth file. The cairo-related errors appears at the end of the file. I cannot exclude that the two commands (cmake and then mingw32-make) which I used are not sufficient for a complete build.
>> 
>> Can you recommend some changes in my build steps which I could try then here?
> 
> I have no direct knowledge of the MinGW-w64/MSYS2 platform, but I keep
> in close touch with the PLplot developer Arjen Markus (who will be
> reading this on the plplot-general mailing list) who has had great
> recent success with the 64-bit MinGW-w64/MSYS2 platform.  That is, you
> will see at <https://sourceforge.net/p/plplot/wiki/Testing_Reports/>
> that Arjen has achieved almost perfect comprehensive test results with
> this platform in October.  So there is excellent hope you will be able
> to achieve that near-perfection as well with PLplot on this platform.
> :-)
> 
> I have just looked at the report from that test (which he shared with
> me), and it appears his pango, and cairo CMake find results were
> similar to the ones you have attached, i.e.,
> 
> irwin@merlin> grep -Ei 'cairo|pango' Arjen.Markus/20181026/MSYS2/shared/noninteractive/output_tree/cmake.out
> -- Checking for module 'pango'
> --   Found pango, version 1.42.1
> -- Checking for module 'pangoft2'
> --   Found pangoft2, version 1.42.1
> -- Checking for module 'pangocairo'
> --   Found pangocairo, version 1.42.1
> -- WARNING: X windows not found. Setting xcairo driver to OFF.
> -- Checking for modules 'lasi;pango;pangoft2'
> -- WARNING: pango, pangoft2, or lasi not found with pkg-config.
> -- WARNING: ENABLE_ocaml is OFF so disabling Plcairo module and lablgtk2 support
> -- Determine compile and link flags for ext-cairo-test
> -- Checking for module 'cairo'
> --   Found cairo, version 1.15.12
> DRIVERS_LIST: cairo;qt;mem;ntk;null;pdf;ps;svg;wingcc;xfig
> DEVICES_LIST: memcairo;extcairo;pdfcairo;pngcairo;pscairo;epscairo;svgcairo;wincairo;pdfqt;qtwidget;bmpqt;jpgqt;pngqt;ppmqt;tiffqt;extqt;memqt;svgqt;mem;ntk;null;pdf;ps;psc;svg;wingcc;xfig
> 
> irwin@merlin> grep -Ei 'cairo|pango' Günter.Kanisch/20190103/MSYS2/text9.txt -- Checking for module 'pango'
> --   Found pango, version 1.43.0
> -- Checking for module 'pangoft2'
> --   Found pangoft2, version 1.43.0
> -- Checking for module 'pangocairo'
> --   Found pangocairo, version 1.43.0
> -- WARNING: X windows not found. Setting xcairo driver to OFF.
> -- Checking for modules 'lasi;pango;pangoft2'
> -- WARNING: pango, pangoft2, or lasi not found with pkg-config.
> -- WARNING: ENABLE_ocaml is OFF so disabling Plcairo module and lablgtk2 support
> -- Determine compile and link flags for ext-cairo-test
> -- Checking for module 'cairo'
> --   Found cairo, version 1.16.0
> DRIVERS_LIST: cairo;mem;ntk;null;pdf;ps;svg;wingcc;xfig
> DEVICES_LIST: memcairo;extcairo;pdfcairo;pngcairo;pscairo;epscairo;svgcairo;wincairo;mem;ntk;null;pdf;ps;psc;svg;wingcc;xfig
> [...] (I have excluded build results to make yours comparable with Arjen's cmake results.)
> 
> So it appears you have found slightly newever versions of the same
> pango and cairo libraries found by Arjen so I don't see any issues with your
> configuration.
> 
> @Arjen: will you double check that please?
> 
> @Günter
> 
> However, a possible issue is you have used the "MinGW-Makefiles"
> generator.  In theory, that is supposed to work correctly on the
> MinGW-w64/MSYS2 platform with mingw32-make, but Arjen has not yet
> tried testing that variant, and it is possible there is some cairo
> configuration issue or even "MinGW-Makefiles" cmake generator issue
> for that case which is not an issue if you use the "Unix Makefiles"
> generator with make (that Arjen used for his test as you can see from
> the wiki test report).
> 
> Furthermore, here are the differences in the actual cairo build between Arjen
> and you.
> 
> Arjen's build result:
> 
> [ 13%] Building C object drivers/CMakeFiles/cairo.dir/cairo.c.obj
> cd D:/plplot-svn/comprehensive_test_disposeable/shared/noninteractive/build_tree/drivers && D:/msys64-new/mingw64/bin/cc.exe -DPLPLOT_HAVE_CONFIG_H -DUSINGDLL -Dcairo_EXPORTS @CMakeFiles/cairo.dir/includes_C.rsp  -mms-bitfields -ID:/msys64-new/mingw64/include/pango-1.0 -ID:/msys64-new/mingw64/include/fribidi -ID:/msys64-new/mingw64/include/cairo -ID:/msys64-new/mingw64/include/pixman-1 -ID:/msys64-new/mingw64/include -ID:/msys64-new/mingw64/include/freetype2 -ID:/msys64-new/mingw64/include -ID:/msys64-new/mingw64/include/harfbuzz -ID:/msys64-new/mingw64/include/glib-2.0 -ID:/msys64-new/mingw64/lib/glib-2.0/include -ID:/msys64-new/mingw64/include -ID:/msys64-new/mingw64/include/libpng16 -ID:/msys64-new/mingw64/include -o CMakeFiles/cairo.dir/cairo.c.obj   -c D:/plplot-svn/plplot-git/drivers/cairo.c
> [ 13%] Linking C shared module ../dll/cairo.dll
> cd D:/plplot-svn/comprehensive_test_disposeable/shared/noninteractive/build_tree/drivers && D:/msys64-new/mingw64/bin/cmake.exe -E remove -f CMakeFiles/cairo.dir/objects.a
> cd D:/plplot-svn/comprehensive_test_disposeable/shared/noninteractive/build_tree/drivers && D:/msys64-new/mingw64/bin/ar.exe cr CMakeFiles/cairo.dir/objects.a @CMakeFiles/cairo.dir/objects1.rsp
> cd D:/plplot-svn/comprehensive_test_disposeable/shared/noninteractive/build_tree/drivers && D:/msys64-new/mingw64/bin/cc.exe    -shared -o ../dll/cairo.dll -Wl,--major-image-version,0,--minor-image-version,0 -Wl,--whole-archive CMakeFiles/cairo.dir/objects.a -Wl,--no-whole-archive @CMakeFiles/cairo.dir/linklibs.rsp
> make[3]: Leaving directory '/d/plplot-svn/comprehensive_test_disposeable/shared/noninteractive/build_tree'
> [ 13%] Built target cairo
> 
> 
> Your result (from the attached file):
> 
> [ 42%] Building C object drivers/CMakeFiles/cairo.dir/cairo.c.obj
> cd /d D:\plplot-5.14.0\buildmingw64\drivers && D:\msys64\mingw64\bin\gcc.exe -DPLPLOT_HAVE_CONFIG_H -DUSINGDLL -Dcairo_EXPORTS @CMakeFiles/cairo.dir/includes_C.rsp  -mms-bitfields -Id:/msys64/mingw64/include/pango-1.0 -Id:/msys64/mingw64/include/fribidi -Id:/msys64/mingw64/include -Id:/msys64/mingw64/include/cairo -Id:/msys64/mingw64/include -Id:/msys64/mingw64/lib/libffi-3.2.1/include -Id:/msys64/mingw64/include/pixman-1 -Id:/msys64/mingw64/include -Id:/msys64/mingw64/include/freetype2 -Id:/msys64/mingw64/include -Id:/msys64/mingw64/include/harfbuzz -Id:/msys64/mingw64/include/glib-2.0 -Id:/msys64/mingw64/lib/glib-2.0/include -Id:/msys64/mingw64/include -Id:/msys64/mingw64/include/libpng16 -Id:/msys64/mingw64/include -o CMakeFiles\cairo.dir\cairo.c.obj   -c D:\plplot-5.14.0\drivers\cairo.c
> [ 42%] Linking C shared module ..\dll\cairo.dll
> cd /d D:\plplot-5.14.0\buildmingw64\drivers && D:\msys64\mingw64\bin\cmake.exe -E cmake_link_script CMakeFiles\cairo.dir\link.txt --verbose=1
> D:\msys64\mingw64\bin\cmake.exe -E remove -f CMakeFiles\cairo.dir/objects.a
> D:\msys64\mingw64\bin\ar.exe cr CMakeFiles\cairo.dir/objects.a @CMakeFiles\cairo.dir\objects1.rsp
> D:\msys64\mingw64\bin\gcc.exe    -shared -o ..\dll\cairo.dll -Wl,--major-image-version,0,--minor-image-version,0 -Wl,--whole-archive CMakeFiles\cairo.dir/objects.a -Wl,--no-whole-archive @CMakeFiles\cairo.dir\linklibs.rsp
> CMakeFiles\cairo.dir/objects.a(cairo.c.obj):cairo.c:(.text+0x1279): undefined reference to `g_object_unref'
> CMakeFiles\cairo.dir/objects.a(cairo.c.obj):cairo.c:(.text+0x16f4): undefined reference to `g_object_unref'
> collect2.exe: error: ld returned 1 exit status
> mingw32-make[2]: *** [drivers\CMakeFiles\cairo.dir\build.make:97: dll/cairo.dll] Error 1
> mingw32-make[2]: Leaving directory 'D:/plplot-5.14.0/buildmingw64'
> mingw32-make[1]: *** [CMakeFiles\Makefile2:1733: drivers/CMakeFiles/cairo.dir/all] Error 2
> mingw32-make[1]: Leaving directory 'D:/plplot-5.14.0/buildmingw64'
> mingw32-make: *** [Makefile:154: all] Error 2
> 
> So it appears your link step for our cairo device driver is quite
> different from Arjen's.  It's possible these differences are due to
> Arjen still using Windows 7 for his last comprehensive test while you
> are using Windows 10.  But ideally CMake should be able to adjust for
> those differences.
> 
> Anyhow, to get closer to the combination that works well for Arjen,
> I suggest you install the msys/bash and msys/make packages
> (which includes the Unix-style "make" command) from the msys archive
> and try the "Unix Makefiles" generator instead with make (run from a
> bash command line).
> 
> Note, if you want to go back to the "MinGW Makefiles" approach after
> trying "Unix Makefiles" (or the very similar "MSYS Makefiles") then
> you will have to remove the msys/bash package which is incompatible
> with the "MinGW Makefiles" generator without a hack I know (remove the
> sh.exe copy of bash.exe) to work around that issue.
> 
> By the way, if you still continue to have cairo linking problems when
> you switch to "Unix Makefiles" generator + msys make, I hope you will
> be willing to send this list a report tarball containing everything we
> need to know.  This is only possible on platforms with bash
> which is another reason for you to install msys/make and msys/bash.
> 
> On such platforms the way you create that tarball
> is simply to run
> 
> scripts/comprehensive_testing.sh
> 
> For a lot of important details about that script please look at
> <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/>
> 
>> By the way: I observed that I do not know the libplplotfortran.dll. Does it replace one/some other dlls I have used previously?
> 
> libplplotfortran contains our modern Fortran binding for PLplot so it
> is essential for you with PLplot-5.14.0 (and also at least one
> previous version).  So I infer you are trying to upgrade from a fairly
> old version of PLplot.  I highly encourage that step because of all
> the bug fixing and new features available with modern PLplot, but it
> does involve some "upgrade pain" for you.  But I hope such discussions
> as these will ease that pain for you.
> 
>> Thank you very much in advance - and all the best for a successful new year!
> 
> Thanks, and you too.
> 
> Alan
> __________________________
> Alan W. Irwin
> 
> 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
> __________________________<text9.txt>_______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general

Re: [Plplot-general] PLPLOT-5.14.0: building cairo.dll fails (Windows 10)

[Alan W. I. <Ala...@gm...>]

Hi Günter:

I have put my reply to your message on the plplot-general mailing list
since your remarks and mine will be of interest to subscribers there.
Therefore, if you have not already subscribed to that list you should do so
now since that is where such support requests are normally addressed.

More below in context.

On 2019-01-03 19:29+0100 Günter Kanisch wrote:

> Dear Alan,
>
> After a longer time having worked with the 32-bit version of plplot under 
> Windows, I want to migrate now to the 64-bit executable of my 
> Fortran/GTK/plplot program.  The fortran mathematics and the GTK gui are 
> already running as an 64-bit executable. However, building now plplot-5.14.0 
> fails with linking the cairo.dll (in the path .. 
> drivers/CMakeFiles/cairo.dir) resulting in two error messages: unknown 
> reference to 'g_object_unref' .
>
> I am working with MSYS2 (installed under d:\msys64\mingw64 under Windows 10); 
> it contains the 64-bitcompilers and GTK and so on, but also mingw32-make.exe.
>
> I tried it for some days now - and could not solve the problem. At least, its 
> seems that cmake finds all the correct 64-bit versions of exe and dll files.
>
> I attach a text file containing the console output of the cmake and 
> thereafter of the mingw32-make command(s), executed by a small bacth file. 
> The cairo-related errors appears at the end of the file. I cannot exclude 
> that the two commands (cmake and then mingw32-make) which I used are not 
> sufficient for a complete build.
>
> Can you recommend some changes in my build steps which I could try then here?

I have no direct knowledge of the MinGW-w64/MSYS2 platform, but I keep
in close touch with the PLplot developer Arjen Markus (who will be
reading this on the plplot-general mailing list) who has had great
recent success with the 64-bit MinGW-w64/MSYS2 platform.  That is, you
will see at <https://sourceforge.net/p/plplot/wiki/Testing_Reports/>
that Arjen has achieved almost perfect comprehensive test results with
this platform in October.  So there is excellent hope you will be able
to achieve that near-perfection as well with PLplot on this platform.
:-)

I have just looked at the report from that test (which he shared with
me), and it appears his pango, and cairo CMake find results were
similar to the ones you have attached, i.e.,

irwin@merlin> grep -Ei 'cairo|pango' Arjen.Markus/20181026/MSYS2/shared/noninteractive/output_tree/cmake.out
-- Checking for module 'pango'
--   Found pango, version 1.42.1
-- Checking for module 'pangoft2'
--   Found pangoft2, version 1.42.1
-- Checking for module 'pangocairo'
--   Found pangocairo, version 1.42.1
-- WARNING: X windows not found. Setting xcairo driver to OFF.
-- Checking for modules 'lasi;pango;pangoft2'
-- WARNING: pango, pangoft2, or lasi not found with pkg-config.
-- WARNING: ENABLE_ocaml is OFF so disabling Plcairo module and lablgtk2 support
-- Determine compile and link flags for ext-cairo-test
-- Checking for module 'cairo'
--   Found cairo, version 1.15.12
DRIVERS_LIST: cairo;qt;mem;ntk;null;pdf;ps;svg;wingcc;xfig
DEVICES_LIST: memcairo;extcairo;pdfcairo;pngcairo;pscairo;epscairo;svgcairo;wincairo;pdfqt;qtwidget;bmpqt;jpgqt;pngqt;ppmqt;tiffqt;extqt;memqt;svgqt;mem;ntk;null;pdf;ps;psc;svg;wingcc;xfig

irwin@merlin> grep -Ei 'cairo|pango' Günter.Kanisch/20190103/MSYS2/text9.txt 
-- Checking for module 'pango'
--   Found pango, version 1.43.0
-- Checking for module 'pangoft2'
--   Found pangoft2, version 1.43.0
-- Checking for module 'pangocairo'
--   Found pangocairo, version 1.43.0
-- WARNING: X windows not found. Setting xcairo driver to OFF.
-- Checking for modules 'lasi;pango;pangoft2'
-- WARNING: pango, pangoft2, or lasi not found with pkg-config.
-- WARNING: ENABLE_ocaml is OFF so disabling Plcairo module and lablgtk2 support
-- Determine compile and link flags for ext-cairo-test
-- Checking for module 'cairo'
--   Found cairo, version 1.16.0
DRIVERS_LIST: cairo;mem;ntk;null;pdf;ps;svg;wingcc;xfig
DEVICES_LIST: memcairo;extcairo;pdfcairo;pngcairo;pscairo;epscairo;svgcairo;wincairo;mem;ntk;null;pdf;ps;psc;svg;wingcc;xfig
[...] (I have excluded build results to make yours comparable with Arjen's cmake results.)

So it appears you have found slightly newever versions of the same
pango and cairo libraries found by Arjen so I don't see any issues with your
configuration.

@Arjen: will you double check that please?

@Günter

However, a possible issue is you have used the "MinGW-Makefiles"
generator.  In theory, that is supposed to work correctly on the
MinGW-w64/MSYS2 platform with mingw32-make, but Arjen has not yet
tried testing that variant, and it is possible there is some cairo
configuration issue or even "MinGW-Makefiles" cmake generator issue
for that case which is not an issue if you use the "Unix Makefiles"
generator with make (that Arjen used for his test as you can see from
the wiki test report).

Furthermore, here are the differences in the actual cairo build between Arjen
and you.

Arjen's build result:

[ 13%] Building C object drivers/CMakeFiles/cairo.dir/cairo.c.obj
cd D:/plplot-svn/comprehensive_test_disposeable/shared/noninteractive/build_tree/drivers && D:/msys64-new/mingw64/bin/cc.exe -DPLPLOT_HAVE_CONFIG_H -DUSINGDLL -Dcairo_EXPORTS @CMakeFiles/cairo.dir/includes_C.rsp  -mms-bitfields -ID:/msys64-new/mingw64/include/pango-1.0 -ID:/msys64-new/mingw64/include/fribidi -ID:/msys64-new/mingw64/include/cairo -ID:/msys64-new/mingw64/include/pixman-1 -ID:/msys64-new/mingw64/include -ID:/msys64-new/mingw64/include/freetype2 -ID:/msys64-new/mingw64/include -ID:/msys64-new/mingw64/include/harfbuzz -ID:/msys64-new/mingw64/include/glib-2.0 -ID:/msys64-new/mingw64/lib/glib-2.0/include -ID:/msys64-new/mingw64/include -ID:/msys64-new/mingw64/include/libpng16 -ID:/msys64-new/mingw64/include -o CMakeFiles/cairo.dir/cairo.c.obj   -c D:/plplot-svn/plplot-git/drivers/cairo.c
[ 13%] Linking C shared module ../dll/cairo.dll
cd D:/plplot-svn/comprehensive_test_disposeable/shared/noninteractive/build_tree/drivers && D:/msys64-new/mingw64/bin/cmake.exe -E remove -f CMakeFiles/cairo.dir/objects.a
cd D:/plplot-svn/comprehensive_test_disposeable/shared/noninteractive/build_tree/drivers && D:/msys64-new/mingw64/bin/ar.exe cr CMakeFiles/cairo.dir/objects.a @CMakeFiles/cairo.dir/objects1.rsp
cd D:/plplot-svn/comprehensive_test_disposeable/shared/noninteractive/build_tree/drivers && D:/msys64-new/mingw64/bin/cc.exe    -shared -o ../dll/cairo.dll -Wl,--major-image-version,0,--minor-image-version,0 -Wl,--whole-archive CMakeFiles/cairo.dir/objects.a -Wl,--no-whole-archive @CMakeFiles/cairo.dir/linklibs.rsp
make[3]: Leaving directory '/d/plplot-svn/comprehensive_test_disposeable/shared/noninteractive/build_tree'
[ 13%] Built target cairo


Your result (from the attached file):

[ 42%] Building C object drivers/CMakeFiles/cairo.dir/cairo.c.obj
cd /d D:\plplot-5.14.0\buildmingw64\drivers && D:\msys64\mingw64\bin\gcc.exe -DPLPLOT_HAVE_CONFIG_H -DUSINGDLL -Dcairo_EXPORTS @CMakeFiles/cairo.dir/includes_C.rsp  -mms-bitfields -Id:/msys64/mingw64/include/pango-1.0 -Id:/msys64/mingw64/include/fribidi -Id:/msys64/mingw64/include -Id:/msys64/mingw64/include/cairo -Id:/msys64/mingw64/include -Id:/msys64/mingw64/lib/libffi-3.2.1/include -Id:/msys64/mingw64/include/pixman-1 -Id:/msys64/mingw64/include -Id:/msys64/mingw64/include/freetype2 -Id:/msys64/mingw64/include -Id:/msys64/mingw64/include/harfbuzz -Id:/msys64/mingw64/include/glib-2.0 -Id:/msys64/mingw64/lib/glib-2.0/include -Id:/msys64/mingw64/include -Id:/msys64/mingw64/include/libpng16 -Id:/msys64/mingw64/include -o CMakeFiles\cairo.dir\cairo.c.obj   -c D:\plplot-5.14.0\drivers\cairo.c
[ 42%] Linking C shared module ..\dll\cairo.dll
cd /d D:\plplot-5.14.0\buildmingw64\drivers && D:\msys64\mingw64\bin\cmake.exe -E cmake_link_script CMakeFiles\cairo.dir\link.txt --verbose=1
D:\msys64\mingw64\bin\cmake.exe -E remove -f CMakeFiles\cairo.dir/objects.a
D:\msys64\mingw64\bin\ar.exe cr CMakeFiles\cairo.dir/objects.a @CMakeFiles\cairo.dir\objects1.rsp
D:\msys64\mingw64\bin\gcc.exe    -shared -o ..\dll\cairo.dll -Wl,--major-image-version,0,--minor-image-version,0 -Wl,--whole-archive CMakeFiles\cairo.dir/objects.a -Wl,--no-whole-archive @CMakeFiles\cairo.dir\linklibs.rsp
CMakeFiles\cairo.dir/objects.a(cairo.c.obj):cairo.c:(.text+0x1279): undefined reference to `g_object_unref'
CMakeFiles\cairo.dir/objects.a(cairo.c.obj):cairo.c:(.text+0x16f4): undefined reference to `g_object_unref'
collect2.exe: error: ld returned 1 exit status
mingw32-make[2]: *** [drivers\CMakeFiles\cairo.dir\build.make:97: dll/cairo.dll] Error 1
mingw32-make[2]: Leaving directory 'D:/plplot-5.14.0/buildmingw64'
mingw32-make[1]: *** [CMakeFiles\Makefile2:1733: drivers/CMakeFiles/cairo.dir/all] Error 2
mingw32-make[1]: Leaving directory 'D:/plplot-5.14.0/buildmingw64'
mingw32-make: *** [Makefile:154: all] Error 2

So it appears your link step for our cairo device driver is quite
different from Arjen's.  It's possible these differences are due to
Arjen still using Windows 7 for his last comprehensive test while you
are using Windows 10.  But ideally CMake should be able to adjust for
those differences.

Anyhow, to get closer to the combination that works well for Arjen,
I suggest you install the msys/bash and msys/make packages
(which includes the Unix-style "make" command) from the msys archive
and try the "Unix Makefiles" generator instead with make (run from a
bash command line).

Note, if you want to go back to the "MinGW Makefiles" approach after
trying "Unix Makefiles" (or the very similar "MSYS Makefiles") then
you will have to remove the msys/bash package which is incompatible
with the "MinGW Makefiles" generator without a hack I know (remove the
sh.exe copy of bash.exe) to work around that issue.

By the way, if you still continue to have cairo linking problems when
you switch to "Unix Makefiles" generator + msys make, I hope you will
be willing to send this list a report tarball containing everything we
need to know.  This is only possible on platforms with bash
which is another reason for you to install msys/make and msys/bash.

On such platforms the way you create that tarball
is simply to run

scripts/comprehensive_testing.sh

For a lot of important details about that script please look at
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/>

> By the way: I observed that I do not know the libplplotfortran.dll. Does it 
> replace one/some other dlls I have used previously?

libplplotfortran contains our modern Fortran binding for PLplot so it
is essential for you with PLplot-5.14.0 (and also at least one
previous version).  So I infer you are trying to upgrade from a fairly
old version of PLplot.  I highly encourage that step because of all
the bug fixing and new features available with modern PLplot, but it
does involve some "upgrade pain" for you.  But I hope such discussions
as these will ease that pain for you.

> Thank you very much in advance - and all the best for a successful new year!

Thanks, and you too.

Alan
__________________________
Alan W. Irwin

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-general] PLplot-5.14.0 has been released

[Alan W. I. <Ala...@gm...>]

On behalf of all the PLplot developers I am happy to announce a new
release of PLplot is now available.  We have put a substantial amount
of effort into this release (some 150 commits), and it is the only
version we support by answering questions here so downloading it and
building it is highly recommended.

For all the details concerning this release please follow the links
given in <https://sourceforge.net/p/plplot/news/2018/12/plplot-5140-has-been-released/>.
Note that the release notes linked there are especially important
because they give details concerning backwards incompatibilities
(an unfortunate necessity to support our on-going but slow battle
against cruft).  Those release notes contain official notices for
users of this release that have the following headings:

* CMake version compatibility
* Remove Fortran cruft
* Remove Tcl/Tk cruft
* Remove plmap cruft
* Remove Perl/PDL examples
* Remove all previously deprecated functions
* Official deprecation of plshade1
* Official deprecation of C++ cruft
* plplot.org and www.plplot.org are now our official domains
* We have removed the "sys" subdirectory from our source tree
* Imported PLplot targets now must use the "PLPLOT::" prefix for the target name
* Drop -single_module linking option that was previously forced for Mac OS X
* Changed color interpolation for plscmap1l and plscmap1la

Those release notes also contain details of improvements for this release that
have the following headings:

* Bug fixes
* Update control of Python version
* Rewrite the build-system logic for determining PYQT_SIP_DIR and PYQT_SIP_FLAGS
* Implement plStatic2dGrid
* Replace use of the deprecated WIN32 and __WIN32__ macros by the _WIN32 macro
* Difference report default device changed from psc to svg
* Resolve the remaining difference report issues
* Improve command-line parsing
* Cleanup of plmap
* wxwidgets development status
* First step toward using best CMake-3 practices for our build system
* Update PLplot to be consistent with modern free software
* Rewrite documentation of PLplot testing
* Configure the ps and psttf device drivers just like all other device drivers

Enjoy this new version of PLplot!

Alan
__________________________
Alan W. Irwin

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-general] Linker Error C++ pkg-config -lplplotd

[Alan W. I. <Ala...@gm...>]

On 2018-12-08 14:53+0100 Andreas Schmid wrote:

> Dear plplot community,
>
> Im running plplot using homebrew on MacOS 10.13.6 High Sierra.
>
>
> Compiling works, linking fails:
>
>
> My (old 2009) Makefile contains:
> PLPLOTDIR := /usr/local/Cellar/plplot/5.13.0_5
> LIB_PLPLOT := -L${PLPLOTDIR}/lib -lplplotd
                                            ^
Hi Andi:

The issue above is the official name of our library is now plplot rather than plplotd.

The OFFICIAL NOTICES FOR USERS for
5.11.0 explains why we made this change in the following section

1.1 Backwards-incompatible change to the suffix for our library names

Although the pace of these changes to clean up PLplot has been
relatively low, a fairly large number of them have accumulated since
2009 so if you run into any other backwards incompatibilities that
affect your old Makefiles, I suggest you first look for answers in other
sections in OFFICIAL NOTICES FOR USERS that have been cumulated for
all our recent releases in the file README.cumulated_release.

By the way, we still do test and support the old Makefile + pkg-config
way to access PLplot.  So you should be fine for all projects you
build with raw Makefiles.  However, for projects which are built with
the aid of CMake to configure Makefiles (or whatever other backend you
choose for CMake), I would recommend you use CMake facilities to
access installed PLplot.  To see an example of one project (our
installed examples) that does that, check out
$prefix/share/plplot$version/examples/CMakeLists.txt, where $prefix is
your install prefix and $version is 5.13.0 now, but will be 5.14.0
when the next release of PLplot comes out (which should be a matter of
days from now).  Note, our installed examples also have a raw Makefile
build system so to keep the two separate make sure you use a separate
build tree if using CMake to build our installed examples against
installed version of PLplot libraries, etc.

Good luck with modern PLplot, and let us know how it goes for you.

Alan
__________________________
Alan W. Irwin

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-general] Linker Error C++ pkg-config -lplplotd

[Andreas S. <and...@gm...>]

Dear plplot community,

Im running plplot using homebrew on MacOS 10.13.6 High Sierra.


Compiling works, linking fails:


My (old 2009) Makefile contains:
PLPLOTDIR := /usr/local/Cellar/plplot/5.13.0_5
LIB_PLPLOT := -L${PLPLOTDIR}/lib -lplplotd


And i get:


c++ -o tobago tobago.o tobago_file.o tobago_GTK.o tobago_plot.o -Wall -g
-export-dynamic `pkg-config --libs gtk+-2.0`
-L/usr/local/Cellar/plplot/5.13.0_5/lib -lplplotd

ld: warning: text-based stub file
/System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and
library file
/System/Library/Frameworks//CoreFoundation.framework/CoreFoundation are out
of sync. Falling back to library file for linking.

ld: library not found for -lplplotd

clang: *error: *linker command failed with exit code 1 (use -v to see
invocation)


make: *** [tobago_GTK] Error 1


how can i use plplot-c++.pc to solve this? Seems that my Makefile is not
working any longer with new plplot.


?

plplot-c++.pc plplot-fortran.pc plplot.pc



Does anyone have an recommendation how to fix the fact that the library can
not be found?


Thank you very much


Regards

Andi

Re: [Plplot-general] Test of plhist problem - it is empty again

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

Hi Sergej,

I think this is due to all your y-data falling in the lowest bin. I used the times instead of the y-data. Plhist may not be the correct routine. Instead plbin takes precomputed bin values and x-values separately. How should the height of the bins be determined?

Regards,

Arjen

Verzonden vanaf mijn Samsung Galaxy-smartphone.


-------- Oorspronkelijk bericht --------
Van: Sergej Scherbina <no...@ro...>
Datum: 22-11-18 20:24 (GMT+01:00)
Aan: "Alan W. Irwin" <Ala...@gm...>, Arjen Markus <Arj...@de...>
Cc: Sergej Scherbina <no...@ro...>, plp...@li...
Onderwerp: RE: [Plplot-general] Test of plhist problem - it is empty again

I have tested it and it is in an attached file

I used
plhist ( NumInpData,  FloatData,    xmin,   xmax,    6,   1  );

and this message disappeared

*** PLPLOT WARNING ***
All pages after the first skipped because family file output not specified.

but plot is strange - with one vertical line only.

Regards,
Sergey.
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-general] Test of plhist problem - it is empty again

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

Hi Sergej,

I think this is due to all your y-data falling in the lowest bin. I used the times instead of the y-data. Plhist may not be the correct routine. Instead plbin takes precomputed bin values and x-values separately. How should the height of the bins be determined?

Regards,

Arjen

Verzonden vanaf mijn Samsung Galaxy-smartphone.


-------- Oorspronkelijk bericht --------
Van: Sergej Scherbina <no...@ro...>
Datum: 22-11-18 20:24 (GMT+01:00)
Aan: "Alan W. Irwin" <Ala...@gm...>, Arjen Markus <Arj...@de...>
Cc: Sergej Scherbina <no...@ro...>, plp...@li...
Onderwerp: RE: [Plplot-general] Test of plhist problem - it is empty again

I have tested it and it is in an attached file

I used
plhist ( NumInpData,  FloatData,    xmin,   xmax,    6,   1  );

and this message disappeared

*** PLPLOT WARNING ***
All pages after the first skipped because family file output not specified.

but plot is strange - with one vertical line only.

Regards,
Sergey.
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-general] Test of plhist problem - it is empty again

[Sergej S. <no...@ro...>]

I have tested it and it is in an attached file

I used 
plhist ( NumInpData,  FloatData,    xmin,   xmax,    6,   1  );

and this message disappeared

*** PLPLOT WARNING ***
All pages after the first skipped because family file output not specified.

but plot is strange - with one vertical line only.

Regards,
Sergey.

Re: [Plplot-general] label distance from axis, plbox

[António R. T. <ar...@gm...>]

Hi thanks for your interest.
Really it is hard to understand what is happening. Just a little background
I have an application that runs in linux, Mac and Windows and as the people
I work with are not in compile and install stuff in their computers they
use a binary of the application. It works pretty well plplot produces a
raster png file  using cairo driver that is then rendered at screen.before
build the plot the available area in pixels is retrieved and sent to plplot

    plsdev(device);

    plsfnam(filename);

    if(xsize && ysize){

        savedxsize=xsize;

        savedysize=ysize;

    }

       if(device.contains("psc")){

          plspage(0.,0.,savedysize,savedxsize,0,-10);

       }else plspage(dpi,dpi,savedxsize,savedysize,0,0);

}

dpi=0.; I used to have zero instead of dpi but lately i tried to test
if there was a change if

 dpi was different from zero. xsize and ysize are the available
pixels. Well in this new windows

 high dpi screens  fonts get bad positioned and scaled but scaled t
was easy to solve. The more strange

is along side

with rendering the png one can choose to save the plot and in those
cases the plot is again built

for a specific file format. Attach is the result in pdf. What is
exactly equal one can see in the screen and

it puzzles me  how can this be related to the screen density as it is
stored directly on file

 (pdf cairo driver)

as in docs says the fonts height is related with the driver so instead

plschr(o.,fontscale);//character height I'm now using

plschr(somefloat.,fontscale);

as eventually plbox could for some reason take 0 as font size.

in attach a pdf plot that the only interaction with screen was getting
savedxsize,savedysize and then made with pdf cairo driver. and yet it
easy to see labels are in wrong place.

Beam.pdf and also another plot Beam_everywhere.pdf as it is obtained
with the same code in all the others computers MAC, Windows and
linux.



I'm not expecting solutions and unfortunately I cannot play with
computer this is happen  otherwise

i would install plplot there and  would test  the examples.


best wishes




On Thu, Nov 22, 2018 at 11:58 AM Arjen Markus <Arj...@de...>
wrote:

> Hi António,
>
>
>
> Could you provide us a screenshot? I do not have such a screen available,
> so I have never encountered the issue. A screenshot might help to clarify
> the cause, as I doubt there is a configuration parameter for that at the
> moment.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
> *From:* António Rodrigues Tomé [mailto:ar...@gm...]
> *Sent:* Thursday, November 22, 2018 12:46 PM
> *To:* Plp...@li...
> *Subject:* [Plplot-general] label distance from axis, plbox
>
>
>
> Hi,
>
> I'm using plplot for quite some time but recently I came across with a
> problem on a High DPI display with windows (only usable by applying a 250%
> zoom  as recommended by windows) in this case  the x axis lines cross the
> numeric  axis labels. I search the documentation for some ways to increase
> the distance between axis numerical labels and the axis line, unfortunately
> I was unable to find anything related. Is there  a way to increase the
> default distance between the numerical  labels and axis line?
>
>
>
> best regards,
>
>
>
>
> --
>
>
> António Rodrigues Tomé
> Universidade da Beira Interior
> Instituto D. Luís (lab associado)
> email address:
> ar...@gm...
> ar...@ub...
> http://www.researcherid.com/rid/A-5681-2013
> 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.
>


-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

Re: [Plplot-general] label distance from axis, plbox

[Jim D. <li...@di...>]

The current windows driver doesn't handle high DPI displays correctly. The windows api calls that are used in plplot predate the high DPI displays. 

I've been a bad contributor on updating the windows driver, so I'll take the blame on this bug! 

> On Nov 22, 2018, at 6:58 AM, Arjen Markus <Arj...@de...> wrote:
> 
> Hi António,
>  
> Could you provide us a screenshot? I do not have such a screen available, so I have never encountered the issue. A screenshot might help to clarify the cause, as I doubt there is a configuration parameter for that at the moment.
>  
> Regards,
>  
> Arjen
>  
> From: António Rodrigues Tomé [mailto:ar...@gm...] 
> Sent: Thursday, November 22, 2018 12:46 PM
> To: Plp...@li...
> Subject: [Plplot-general] label distance from axis, plbox
>  
> Hi,
> I'm using plplot for quite some time but recently I came across with a problem on a High DPI display with windows (only usable by applying a 250% zoom  as recommended by windows) in this case  the x axis lines cross the  numeric  axis labels. I search the documentation for some ways to increase the distance between axis numerical labels and the axis line, unfortunately I was unable to find anything related. Is there  a way to increase the default distance between the numerical  labels and axis line? 
>  
> best regards,
> 
>  
> --
> 
> António Rodrigues Tomé
> Universidade da Beira Interior
> Instituto D. Luís (lab associado)
> email address:
> ar...@gm...
> ar...@ub...
> http://www.researcherid.com/rid/A-5681-2013
> 
> 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.
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general

Re: [Plplot-general] label distance from axis, plbox

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

Hi António,

Could you provide us a screenshot? I do not have such a screen available, so I have never encountered the issue. A screenshot might help to clarify the cause, as I doubt there is a configuration parameter for that at the moment.

Regards,

Arjen

From: António Rodrigues Tomé [mailto:ar...@gm...]
Sent: Thursday, November 22, 2018 12:46 PM
To: Plp...@li...
Subject: [Plplot-general] label distance from axis, plbox

Hi,
I'm using plplot for quite some time but recently I came across with a problem on a High DPI display with windows (only usable by applying a 250% zoom  as recommended by windows) in this case  the x axis lines cross the  numeric  axis labels. I search the documentation for some ways to increase the distance between axis numerical labels and the axis line, unfortunately I was unable to find anything related. Is there  a way to increase the default distance between the numerical  labels and axis line?

best regards,


--

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...<mailto:ar...@gm...>
ar...@ub...<mailto:ar...@ub...>
http://www.researcherid.com/rid/A-5681-2013
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.

[Plplot-general] label distance from axis, plbox

[António R. T. <ar...@gm...>]

Hi,
I'm using plplot for quite some time but recently I came across with a
problem on a High DPI display with windows (only usable by applying a 250%
zoom  as recommended by windows) in this case  the x axis lines cross the
numeric  axis labels. I search the documentation for some ways to increase
the distance between axis numerical labels and the axis line, unfortunately
I was unable to find anything related. Is there  a way to increase the
default distance between the numerical  labels and axis line?

best regards,


-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

Re: [Plplot-general] Test of plhist problem - it is empty again

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

Hi Alan, Sergej,

> -----Original Message-----
> From: Alan W. Irwin [mailto:Ala...@gm...]
> Sent: Wednesday, November 21, 2018 9:13 AM
>
> Your result suggested to me the possibility that plhist had a memory management
> issue so I checked that possibility with valgrind, and the result was perfect, i.e.,
>
...
>
> So from these results I think our plhist source code should be fine.
> Of course, the perfect valgrind results here mean I have no clue at all why you are
> running into intermittent trouble with plhist there.
> Sorry I cannot help more, but I wish you the best of luck in figuring out the issue on
> your platform.
>
The coredump seems to have been due to a mistake in the print statement - at least I found a small bug in there and when I rebuilt PLplot and the test program that coredump was gone.

Solving the non-amuzing build problem was easier than I thought: I now use the newer CMake version that I built on Cygwin, not the one that comes with the platform. I used that in the comprehensive tests, but not yet to build the libraries and examples on their own. While it is good to be able to build PLplot again without any problems, it is a riddle why the stock version of CMake does not work. As I get a new computer next week, I will have the opportunity to re-install Cygwin and see whether this was simply a quirk (may I blame it on alpha particles or the  phase of the moon?) or something more serious.

To Sergej:
The good news is that I have been able to get the histogram to be drawn. Instead of 0 I use as option to the plhist() routine a value of 1. This forces it not to redefine the window (not to call plenv()).

As to why a value of 0 causes it to produce an empty plot, is something I would like to find out - it works in  example x05c after all.

See the attached picture (I used 6 bins instead of 11, to see if the bins are done correctly).

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-general] Test of plhist problem - it is empty again

[Alan W. I. <Ala...@gm...>]

On 2018-11-21 07:48-0000 Arjen Markus wrote:

> Hi Alan,
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:Ala...@gm...]
>> Sent: Tuesday, November 20, 2018 10:21 AM
>>
>> Hi Arjen:
>>
>> That indeed looks like a good starting point for the failing test case.  But
>> fundamental debugging principles support the idea that another starting point that
>> uses plhist with success should be a big help to find out what is wrong with the
>> failing call to plhist.
>>
>> So I have the same question for you that I asked Sergey.  If you try using the code
>> from example 5 do you get the same rendered result as displayed at
>> <http://plplot.org/examples.php?demo=05>, i.e., plhist success?  Once you have a
>> succeeding test case and failing test case with plhist, then finding what the trouble
>> is with the failing test case should be completely straightforward.
>>
> I can confirm that the plot I get with x05c is very simular to that picture.
>
> However, I encountered a very strange and very unwelcome problem:
> When I added a few print statements to the plhist routine to find out what is going on, I had a coredump - I assume that is due to my print statements, though I just checked and did not see anything much that could cause that. To make sure no stray bits and pieces influenced this, I tried to rebuild the whole library and then, out of the blue!, CMake produced errors and failed to generate the makefiles. It complained for instance about files with a .cxx extension being unknown and no Fortran compiler being found.
>
> I have now started the comprehensive test script and that works fine! I am unhappily surprised about this. I will try to find out what on Earth is going on/wrong, but it may not be before tomorrow that I can really dig into this.

Your result suggested to me the possibility that plhist had a memory management issue
so I checked that possibility with valgrind, and the result was perfect, i.e.,

software@merlin> valgrind examples/c/x05c -dev svg -o test.svg
==5140== Memcheck, a memory error detector
==5140== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==5140== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==5140== Command: examples/c/x05c -dev svg -o test.svg
==5140== 
==5140== 
==5140== HEAP SUMMARY:
==5140==     in use at exit: 0 bytes in 0 blocks
==5140==   total heap usage: 604 allocs, 604 frees, 221,518 bytes allocated
==5140== 
==5140== All heap blocks were freed -- no leaks are possible
==5140== 
==5140== For counts of detected and suppressed errors, rerun with: -v
==5140== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

So from these results I think our plhist source code should be fine.
Of course, the perfect valgrind results here mean I have no clue at
all why you are running into intermittent trouble with plhist there.
Sorry I cannot help more, but I wish you the best of luck in figuring
out the issue on your platform.

Alan
__________________________
Alan W. Irwin

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-general] Test of plhist problem - it is empty again

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

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:Ala...@gm...]
> Sent: Tuesday, November 20, 2018 10:21 AM
>
> Hi Arjen:
>
> That indeed looks like a good starting point for the failing test case.  But
> fundamental debugging principles support the idea that another starting point that
> uses plhist with success should be a big help to find out what is wrong with the
> failing call to plhist.
>
> So I have the same question for you that I asked Sergey.  If you try using the code
> from example 5 do you get the same rendered result as displayed at
> <http://plplot.org/examples.php?demo=05>, i.e., plhist success?  Once you have a
> succeeding test case and failing test case with plhist, then finding what the trouble
> is with the failing test case should be completely straightforward.
>
I can confirm that the plot I get with x05c is very simular to that picture.

However, I encountered a very strange and very unwelcome problem:
When I added a few print statements to the plhist routine to find out what is going on, I had a coredump - I assume that is due to my print statements, though I just checked and did not see anything much that could cause that. To make sure no stray bits and pieces influenced this, I tried to rebuild the whole library and then, out of the blue!, CMake produced errors and failed to generate the makefiles. It complained for instance about files with a .cxx extension being unknown and no Fortran compiler being found.

I have now started the comprehensive test script and that works fine! I am unhappily surprised about this. I will try to find out what on Earth is going on/wrong, but it may not be before tomorrow that I can really dig into 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-general] Test of plhist problem - it is empty again

[Alan W. I. <Ala...@gm...>]

On 2018-11-20 07:49-0000 Arjen Markus wrote:

> When I had corrected the immediate problem by setting the two variables to more reasonable values, I got a nice xy-plot and an empty histogram. Then I looked at the implementation of plhist() - and realised that it is meant to plot a distribution of the data. The data that are passed should match the x-axis, in this case the times, and the minimum and maximum on which to base the bins should match the x-axis as well. However, the code as I have been using it from the tarfile, passes the y-values (FloatData) and the minimum and maximum times.
>
> So I changed the argument to FloatDate instead. The plot is still empty though, the 22 data points do not show up in any way. At least this gives us a starting point to analyse the problem.

Hi Arjen:

That indeed looks like a good starting point for the failing test
case.  But fundamental debugging principles support the idea that
another starting point that uses plhist with success should be a big
help to find out what is wrong with the failing call to plhist.

So I have the same question for you that I asked Sergey.  If you try
using the code from example 5 do you get the same rendered result as
displayed at <http://plplot.org/examples.php?demo=05>, i.e., plhist
success?  Once you have a succeeding test case and failing test case
with plhist, then finding what the trouble is with the failing test
case should be completely straightforward.

Alan
__________________________
Alan W. Irwin

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-general] Test of plhist problem - it is empty again

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

Hi Sergey, Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:Ala...@gm...]
> Sent: Monday, November 19, 2018 8:23 PM
> To: Arjen Markus
> Cc: Sergej Scherbina; plp...@li...
> Subject: Re: [Plplot-general] Test of plhist problem - it is empty again
>
> On 2018-11-19 07:38-0000 Arjen Markus wrote:
>
> > Hi Sergey,
> >
> > Odd, it is something I will have to check more closely then. I have used the trunk
> by the way, but I am not aware that things have changed much in that part of the
> code.
>
Last night, I had a closer look at what was going on and it turned out that the variables FloatStartDate and FloatStoptDate (there seems to be one "t" too many in there ;)) got values that were outside the range of the data in the input file. I used "2018-10-08 00:00:00.110 2018-10-17 00:00:00.129" as the relevant arguments - as from the example, but it may be that on the Cygwin platform I used the times are converted differently. This explains the error message I got: there were no data on which to base the extremes.

> To Arjen and Sergey:
>
> I have done that close check for the current tip of the master branch (which is going
> to be changed only in a minimal way when the 5.14.0 release is completed).  And
> all is well with our plhist call there, i.e., it produces the expected non-empty
> histogram.
>
> @Sergey:
>
> I suggest you look closely at standard example 5 (the only one that uses plhist).  If
> you build it and also some device, then
>
> examples/c/x05c -dev <some_device>
>
> just works correctly for my Debian Buster platform.  That is, it shows the desired
> histogram, i.e., exactly the same rendered results as can be seen at
> <http://plplot.org/examples.php?demo=05>.
>
> Do you get that same histogram result if you replace your code with that from
> standard example 5?  If so, then the next obvious question is what changes you
> have made from that good plhist call in standard example 5 to the call in your own
> code that is causing an empty histogram for you.
>
When I had corrected the immediate problem by setting the two variables to more reasonable values, I got a nice xy-plot and an empty histogram. Then I looked at the implementation of plhist() - and realised that it is meant to plot a distribution of the data. The data that are passed should match the x-axis, in this case the times, and the minimum and maximum on which to base the bins should match the x-axis as well. However, the code as I have been using it from the tarfile, passes the y-values (FloatData) and the minimum and maximum times.

So I changed the argument to FloatDate instead. The plot is still empty though, the 22 data points do not show up in any way. At least this gives us a starting point to analyse the problem.

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-general] Test of plhist problem - it is empty again

[Alan W. I. <Ala...@gm...>]

On 2018-11-19 07:38-0000 Arjen Markus wrote:

> Hi Sergey,
>
> Odd, it is something I will have to check more closely then. I have used the trunk by the way, but I am not aware that things have changed much in that part of the code.

To Arjen and Sergey:

I have done that close check for the current tip of the master branch (which is going to be changed
only in a minimal way when the 5.14.0 release is completed).  And all is well with our plhist
call there, i.e., it produces the expected non-empty histogram.

@Sergey:

I suggest you look closely at standard example 5 (the only one that uses plhist).  If you build it
and also some device, then

examples/c/x05c -dev <some_device>

just works correctly for my Debian Buster platform.  That is, it shows the desired histogram, i.e.,
exactly the same rendered results as can be seen at <http://plplot.org/examples.php?demo=05>.

Do you get that same histogram result if you replace your code with
that from standard example 5?  If so, then the next obvious question
is what changes you have made from that good plhist call in standard
example 5 to the call in your own code that is causing an empty
histogram for you.

Alan
__________________________
Alan W. Irwin

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-general] Test of plhist problem - it is empty again

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

Hi Sergey,

Odd, it is something I will have to check more closely then. I have used the trunk by the way, but I am not aware that things have changed much in that part of the code.

Regards,

Arjen

> -----Original Message-----
> From: Sergej Scherbina [mailto:no...@ro...]
> Sent: Sunday, November 18, 2018 1:23 PM
> To: Arjen Markus
> Cc: plp...@li...
> Subject: RE: [Plplot-general] Test of plhist problem - it is empty again
>
> Dear Arjen,
>
> I don't know what it happened with your variants of plline. I don't have this problem.
> In attached files are my both variants - with plline (filled plot) and plhist (empty plot).
>
> Regards,
> Sergey.
>
> PS.
>
> ./PlPlotHISTbyMySQLSelectx002b SELECT_COUNT_EQ_MIDDLE_17963.dat
> OutTxtFile SELECT_COUNT_EQ_MIDDLE_17963x002a.png png
> HISTOGRAM_EQ 2018-10-08 00:00:00.110 2018-10-17 00:00:00.129
> QUANTITY_EQ DATE_DAY_HOUR 3
>
>   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
>   0000. START TIME --> Sun Nov 18 12:12:15 2018
>
>  0000A. ARGS:  Time Left->2018-10-08 00:00:00.110 Time Righ->2018-10-17
> 00:00:00.129 QUANTITY_EQ DATE_DAY_HOUR 3
>   0001B. StrTimeLeft->2018-10-08 00:00:00.110   StrTimeRigh->2018-10-17
> 00:00:00.129
>   0002B. DigitStrTimeLeft->.110   DigitStrTimeRigh->.129
>   0001C. FloatTimeLeft->1538956800.000000    FloatTimeRigh-
> >1539734400.000000
>   0002C. FloatTimeLeft->1538956800.110000    FloatTimeRigh-
> >1539734400.129000
>   0001A. For channel: SELECT_COUNT_EQ_MIDDLE_17963.dat Count_RecsX-
> >74  FloatDataX0[74]--> 9.000000
>   000C1. StartTimeL=> 2018-10-09 15:10:50   StoptTimeL=> 2018-10-13 10:14:35
>   000C2. StartTimeR=> 2018-10-09 16:25:41   StoptTimeR=> 2018-10-13 11:29:26
>   title00->HISTOGRAM_EQ argv[5]->HISTOGRAM_EQ
>   title10->HISTOGRAM_EQ argv[5]->HISTOGRAM_EQ
>
>   XXXX. STOPT TIME --> Sun Nov 18 12:12:16 2018
>
>
> ./PlPlotHISTbyMySQLSelectx002c SELECT_COUNT_EQ_MIDDLE_17963.dat
> OutTxtFile SELECT_COUNT_EQ_MIDDLE_17963xTESTx002a.png png
> HISTOGRAM_EQ 2018-10-08 00:00:00.110 2018-10-17 00:00:00.129
> QUANTITY_EQ DATE_DAY_HOUR 3
>
>   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
>   0000. START TIME --> Sun Nov 18 12:20:49 2018
>   0000A. ARGS:  Time Left->2018-10-08 00:00:00.110 Time Righ->2018-10-17
> 00:00:00.129 QUANTITY_EQ DATE_DAY_HOUR 3
>   0001B. StrTimeLeft->2018-10-08 00:00:00.110   StrTimeRigh->2018-10-17
> 00:00:00.129
>   0002B. DigitStrTimeLeft->.110   DigitStrTimeRigh->.129
>   0001C. FloatTimeLeft->1538956800.000000    FloatTimeRigh-
> >1539734400.000000
>   0002C. FloatTimeLeft->1538956800.110000    FloatTimeRigh-
> >1539734400.129000
>   0001A. For channel: SELECT_COUNT_EQ_MIDDLE_17963.dat Count_RecsX-
> >74  FloatDataX0[74]--> 9.000000
>  000C1. StartTimeL=> 2018-10-09 15:10:50   StoptTimeL=> 2018-10-13 10:14:35
>  000C2. StartTimeR=> 2018-10-09 16:25:41   StoptTimeR=> 2018-10-13 11:29:26
>  title00->HISTOGRAM_EQ argv[5]->HISTOGRAM_EQ  title10->HISTOGRAM_EQ
> argv[5]->HISTOGRAM_EQ
>
> *** PLPLOT WARNING ***
> All pages after the first skipped because family file output not specified.
>
>   XXXX. STOPT TIME --> Sun Nov 18 12:20:49 2018
>
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-general] Test of plhist problem - it is empty again

[Sergej S. <no...@ro...>]

Dear Arjen,

I don't know what it happened with your variants of plline. I don't have this problem.
In attached files are my both variants - with plline (filled plot) and plhist (empty plot).

Regards,
Sergey.

PS.

./PlPlotHISTbyMySQLSelectx002b SELECT_COUNT_EQ_MIDDLE_17963.dat OutTxtFile SELECT_COUNT_EQ_MIDDLE_17963x002a.png png HISTOGRAM_EQ 2018-10-08 00:00:00.110 2018-10-17 00:00:00.129 QUANTITY_EQ DATE_DAY_HOUR 3      

  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  0000. START TIME --> Sun Nov 18 12:12:15 2018
 
 0000A. ARGS:  Time Left->2018-10-08 00:00:00.110 Time Righ->2018-10-17 00:00:00.129 QUANTITY_EQ DATE_DAY_HOUR 3 
  0001B. StrTimeLeft->2018-10-08 00:00:00.110   StrTimeRigh->2018-10-17 00:00:00.129 
  0002B. DigitStrTimeLeft->.110   DigitStrTimeRigh->.129 
  0001C. FloatTimeLeft->1538956800.000000    FloatTimeRigh->1539734400.000000 
  0002C. FloatTimeLeft->1538956800.110000    FloatTimeRigh->1539734400.129000 
  0001A. For channel: SELECT_COUNT_EQ_MIDDLE_17963.dat Count_RecsX->74  FloatDataX0[74]--> 9.000000  
  000C1. StartTimeL=> 2018-10-09 15:10:50   StoptTimeL=> 2018-10-13 10:14:35 
  000C2. StartTimeR=> 2018-10-09 16:25:41   StoptTimeR=> 2018-10-13 11:29:26 
  title00->HISTOGRAM_EQ argv[5]->HISTOGRAM_EQ 
  title10->HISTOGRAM_EQ argv[5]->HISTOGRAM_EQ 

  XXXX. STOPT TIME --> Sun Nov 18 12:12:16 2018


./PlPlotHISTbyMySQLSelectx002c SELECT_COUNT_EQ_MIDDLE_17963.dat OutTxtFile SELECT_COUNT_EQ_MIDDLE_17963xTESTx002a.png png HISTOGRAM_EQ 2018-10-08 00:00:00.110 2018-10-17 00:00:00.129 QUANTITY_EQ DATE_DAY_HOUR 3

  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  0000. START TIME --> Sun Nov 18 12:20:49 2018
  0000A. ARGS:  Time Left->2018-10-08 00:00:00.110 Time Righ->2018-10-17 00:00:00.129 QUANTITY_EQ DATE_DAY_HOUR 3 
  0001B. StrTimeLeft->2018-10-08 00:00:00.110   StrTimeRigh->2018-10-17 00:00:00.129 
  0002B. DigitStrTimeLeft->.110   DigitStrTimeRigh->.129 
  0001C. FloatTimeLeft->1538956800.000000    FloatTimeRigh->1539734400.000000 
  0002C. FloatTimeLeft->1538956800.110000    FloatTimeRigh->1539734400.129000 
  0001A. For channel: SELECT_COUNT_EQ_MIDDLE_17963.dat Count_RecsX->74  FloatDataX0[74]--> 9.000000  
 000C1. StartTimeL=> 2018-10-09 15:10:50   StoptTimeL=> 2018-10-13 10:14:35 
 000C2. StartTimeR=> 2018-10-09 16:25:41   StoptTimeR=> 2018-10-13 11:29:26 
 title00->HISTOGRAM_EQ argv[5]->HISTOGRAM_EQ 
 title10->HISTOGRAM_EQ argv[5]->HISTOGRAM_EQ 

*** PLPLOT WARNING ***
All pages after the first skipped because family file output not specified.

  XXXX. STOPT TIME --> Sun Nov 18 12:20:49 2018
 

[Plplot-general] All data and C codes are in attached archive file TAR.GZ for test of plhist problem

[Sergej S. <no...@ro...>]

 Hi all!
 
 What is in attached files :
 
 Input data  (SELECT_COUNT_EQ_MIDDLE_17963.dat), the source of both C  files with different forms of plots and their results as PNG
 files. 
 
 How to run  them after compilation :
 
 ./PlPlotHISTbyMySQLSelectx002c  SELECT_COUNT_EQ_MIDDLE_17963.dat OutTxtFile  SELECT_COUNT_EQ_MIDDLE_17963xTEST.png png HISTOGRAM_EQ  2018-10-08 00:00:00.110 2018-10-17 00:00:00.129 QUANTITY_EQ  DATE_DAY_HOUR 3
   
 1) PlPlotHISTbyMySQLSelectx002c.c -  with plhist - it has a problem
 ** PLPLOT WARNING ***  All pages after the first skipped  because family file output not specified.
 
 2) PlPlotHISTbyMySQLSelectx002b.c -  with plline - it works excellently
 
 Regards,
 Sergey.
 
 

[Plplot-general] How to use the plhist with temporal format X data in plbox

[Sergej S. <no...@ro...>]

Hi all! 

We wanted to use the time for X format but it was finished unsuccessfully - we had received empty plot. 

Is it possible to use this combination plbox( "bcnstd", 0.0 , 0.0, "bcnstv", 0.0, 0.0 ) + plhist( NumInpData, FloatData, xmin, xmax, 11, 0 ) at all?


  plbox( "bcnstd", 0.0 , 0.0, "bcnstv", 0.0, 0.0 );

  plcol0( 2 );
  
  pllab( titleX, titleY, title );

  plwidth( 4 );
  
  plhist( NumInpData, FloatData, xmin, xmax, 11, 0 );



Regards,
Sergey.