plplot-devel — Technical discussion about PLplot development

[Plplot-devel] Install a convenience GNAT project for the Ada binding

[Rafael L. <ra...@la...>]

Dear PLplot developers,

We are currently applying the patch attached to this message when 
building the plplot package for Debian. It is authored by Nicolas 
Boulenguez and is intended to install a convenience GNAT project for the 
Ada binding, better fitting the current Ada standard in Debian. According 
to Nicolas, “It is more and more common to build Ada sources with 
gprbuild.”

You might be interested to integrate this patch to the PLplot sources.

Best,

Rafael Laboissière

Re: [Plplot-devel] CMake fails to detect NaN for Fortran

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

Hi Rafael,

I overlooked the patch you attached. This is certainly a workaround, but the function isnan (in the guise of myisnan) is called by a single example only. Like I stated, most compilers support the ieee_is_nan standard function nowadays, so I suggest we clean this up more thoroughly.

Regards,

Arjen (slightly distracted by pressing matters, not a good time to answer e-mails like this)

-----Original Message-----
From: Rafael Laboissière <ra...@la...>
Sent: 30 November 2022 12:40
To: PLplot development list <plp...@li...>
Subject: [Plplot-devel] CMake fails to detect NaN for Fortran

Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de..." as an attachment.


Dear PLplot developers,

When building the plplot package for Debian, using the latest version of gfortran:

     $ gfortran --version | head -n1
     GNU Fortran (Debian 12.2.0-9) 12.2.0

The CMake configuration fails to detect the NaN capability:

     -- Check if isnan function is available in fortran
     -- Check for isnan in fortran - not found

I see the following in CMakeFiles/CMakeError.log:

     Determining if fortran has isnan function failed with the following output:
     Change Dir: [path]/plplot/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp

     Run Build Command(s):/usr/bin/gmake -f Makefile cmTC_58c30/fast && gmake[2]: Entering directory '[path]/plplot/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
     /usr/bin/gmake  -f CMakeFiles/cmTC_58c30.dir/build.make CMakeFiles/cmTC_58c30.dir/build
     gmake[3]: Entering directory '[path]/plplot/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
     Building Fortran object CMakeFiles/cmTC_58c30.dir/TestFortranIsnan.f.o
     /usr/bin/gfortran   -g -O2 -ffile-prefix-map=[path]/plplot=. -fstack-protector-strong -fvisibility=hidden  -c [path]/plplot/cmake/modules/TestFortran
     Isnan.f -o CMakeFiles/cmTC_58c30.dir/TestFortranIsnan.f.o
     [path]/plplot/cmake/modules/TestFortranIsnan.f:5:19:

         5 |       if (isnan(0.0/0.0)) then
           |                   1
     Error: Division by zero at (1)
     [path]/plplot/cmake/modules/TestFortranIsnan.f:7:9:

         7 |       endif
           |         1
     Error: Expecting END PROGRAM statement at (1)
     gmake[3]: *** [CMakeFiles/cmTC_58c30.dir/build.make:78: CMakeFiles/cmTC_58c30.dir/TestFortranIsnan.f.o] Error 1

The patch attached to this message fixes the problem. I think that the problems arises because the gfortran compiler is trying to do the computation "0.0/0.0" at compile-time.

Best,

Rafael Laboissière
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] CMake fails to detect NaN for Fortran

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

Hi Rafael,

Hm, that means that the compiler detects the problem at compile time. As compilers get better all the time, shortcuts like these will fail from time to time. I would have to investigate what the best way is to solve this. (Most compilers support the standard function ieee_is_nan() now, so I suspect this check is superfluous or needs to be transformed altogether.)

Regards,

Arjen


-----Original Message-----
From: Rafael Laboissière <ra...@la...>
Sent: 30 November 2022 12:40
To: PLplot development list <plp...@li...>
Subject: [Plplot-devel] CMake fails to detect NaN for Fortran

Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de..." as an attachment.


Dear PLplot developers,

When building the plplot package for Debian, using the latest version of gfortran:

     $ gfortran --version | head -n1
     GNU Fortran (Debian 12.2.0-9) 12.2.0

The CMake configuration fails to detect the NaN capability:

     -- Check if isnan function is available in fortran
     -- Check for isnan in fortran - not found

I see the following in CMakeFiles/CMakeError.log:

     Determining if fortran has isnan function failed with the following output:
     Change Dir: [path]/plplot/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp

     Run Build Command(s):/usr/bin/gmake -f Makefile cmTC_58c30/fast && gmake[2]: Entering directory '[path]/plplot/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
     /usr/bin/gmake  -f CMakeFiles/cmTC_58c30.dir/build.make CMakeFiles/cmTC_58c30.dir/build
     gmake[3]: Entering directory '[path]/plplot/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
     Building Fortran object CMakeFiles/cmTC_58c30.dir/TestFortranIsnan.f.o
     /usr/bin/gfortran   -g -O2 -ffile-prefix-map=[path]/plplot=. -fstack-protector-strong -fvisibility=hidden  -c [path]/plplot/cmake/modules/TestFortran
     Isnan.f -o CMakeFiles/cmTC_58c30.dir/TestFortranIsnan.f.o
     [path]/plplot/cmake/modules/TestFortranIsnan.f:5:19:

         5 |       if (isnan(0.0/0.0)) then
           |                   1
     Error: Division by zero at (1)
     [path]/plplot/cmake/modules/TestFortranIsnan.f:7:9:

         7 |       endif
           |         1
     Error: Expecting END PROGRAM statement at (1)
     gmake[3]: *** [CMakeFiles/cmTC_58c30.dir/build.make:78: CMakeFiles/cmTC_58c30.dir/TestFortranIsnan.f.o] Error 1

The patch attached to this message fixes the problem. I think that the problems arises because the gfortran compiler is trying to do the computation "0.0/0.0" at compile-time.

Best,

Rafael Laboissière
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-devel] CMake fails to detect NaN for Fortran

[Rafael L. <ra...@la...>]

Dear PLplot developers,

When building the plplot package for Debian, using the latest version 
of gfortran:

     $ gfortran --version | head -n1
     GNU Fortran (Debian 12.2.0-9) 12.2.0

The CMake configuration fails to detect the NaN capability:

     -- Check if isnan function is available in fortran
     -- Check for isnan in fortran - not found

I see the following in CMakeFiles/CMakeError.log:

     Determining if fortran has isnan function failed with the following output:
     Change Dir: [path]/plplot/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp

     Run Build Command(s):/usr/bin/gmake -f Makefile cmTC_58c30/fast && gmake[2]: Entering directory '[path]/plplot/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
     /usr/bin/gmake  -f CMakeFiles/cmTC_58c30.dir/build.make CMakeFiles/cmTC_58c30.dir/build
     gmake[3]: Entering directory '[path]/plplot/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
     Building Fortran object CMakeFiles/cmTC_58c30.dir/TestFortranIsnan.f.o
     /usr/bin/gfortran   -g -O2 -ffile-prefix-map=[path]/plplot=. -fstack-protector-strong -fvisibility=hidden  -c [path]/plplot/cmake/modules/TestFortran
     Isnan.f -o CMakeFiles/cmTC_58c30.dir/TestFortranIsnan.f.o
     [path]/plplot/cmake/modules/TestFortranIsnan.f:5:19:

         5 |       if (isnan(0.0/0.0)) then
           |                   1
     Error: Division by zero at (1)
     [path]/plplot/cmake/modules/TestFortranIsnan.f:7:9:

         7 |       endif
           |         1
     Error: Expecting END PROGRAM statement at (1)
     gmake[3]: *** [CMakeFiles/cmTC_58c30.dir/build.make:78: CMakeFiles/cmTC_58c30.dir/TestFortranIsnan.f.o] Error 1

The patch attached to this message fixes the problem. I think that the 
problems arises because the gfortran compiler is trying to do the 
computation "0.0/0.0" at compile-time.

Best,

Rafael Laboissière

Re: [Plplot-devel] Native build problems when cross-compiling PLplot

[Sebastian E. <aw...@gm...>]

Hi Arjen,

I saw the thread but couldn't figure out how to reply on it (did not
find a way to get the Message-ID for the thread on SF). The cross build
info from the wiki was indeed helpful, but I'm currently stuck with
getting the native build in my cross build environment running, so it
is kind of a different topic ;).

The cross-compiling works well, just got the MacOS/arm64 build to pass,
so this is not really a problem.

However, for Linux cross builds there is one configure step for
lib/qsastime/tai-utc-gen which finds the wrong sysroot in
pc_libplplot_LINK_FLAGS and therefore the native build fails because
the host platform libm is linked.

All the best
Sebastian


On Thu, 2022-02-24 at 12:00 +0000, Arjen Markus wrote:
> Hi Sebastian,
> 
> Alan informed me about earlier experiences with cross-compilation. I copy his answer below:
> 
> ===
> Hi Arjen:
> 
> Andrew Ross got cross-compilation to work (with some limitations) back in 2009.  I suggest if you haven't done so already you review that mailing list thread (which you can find with a subject line search for "cross compilation" in the plplot_devel mailing list archive at SF).
> 
> Andrew commented in that thread that he had documented some of his cross-compilation experiences in our old wiki.  All the contents of that old wiki were transferred to our SF wiki back when I established that SF wiki so his (dated) documentation/comments about cross-compilation should be accessible at our SF wiki.  Indeed, if you search there, there are 7 wiki pages that mention "cross" so if you follow up on those hits (which I did not) I assume you will find what Andrew (and others?) wrote about cross compilation back in 2009 or so.
> 
> Of course, if you make some modern progress with cross-compilation, please update the SF wiki accordingly following the wiki update procedure in README.developers.
> 
> Cheers,
> 
> Alan
> ===
> 
> I have not had time yet to look into this information or the mailing list's archive.
> 
> Regards,
> 
> Arjen
> 
> 
> 
> -----Original Message-----
> From: Sebastian Ehlert <aw...@gm...>
> Sent: 24 February 2022 12:15
> To: plp...@li...
> Subject: [Plplot-devel] Native build problems when cross-compiling PLplot
> 
> Hi everybody,
> 
> I'm currently trying to cross-compile PLplot for Linux/ppc64le,
> Linux/aarch64 and MacOS/arm64 using the conda-forge toolchain [1].
> 
> [1]:https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fconda-forge%2Fplplot-feedstock%2Fpull%2F1&amp;data=04%7C01%7C%7C2ffc86b57cc94f978ced08d9f787029c%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C637812981507864811%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=NP%2F81%2BvuCTVIY6lONGAiDo%2Ff6BKxJVemV0s%2F2hO%2BP%2BU%3D&amp;reserved=0
> 
> From the PLplot wiki [2] I figured I need a native build first, to get access to some intermediary binaries, which are than used in a cross build done in a second step. However, getting the native build running in the cross environment is giving me some grief. Linking lib/qsastime/tai-utc-gen in the native build fails for me because I can't get CMake to *not* find and *not* prefer the sysroot of cross- compiler (pc_libplplot_LINK_FLAGS is including the libm for the host platform).
> 
> [2]:https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fplplot%2Fwiki%2FBuilding_PLplot_with_a_cross-compiler%2F&amp;data=04%7C01%7C%7C2ffc86b57cc94f978ced08d9f787029c%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C637812981507864811%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=ygGiPYPnsA57l4xNzMut1kuit6QcmWOgADzapiNu2F4%3D&amp;reserved=0
> 
> What I can't do is have two different environments here (native first and cross later), because I run inside conda-build to make the packaging automatic with the conda-forge toolchain for future PLplot releases. While I can install a native PLplot version and point to its prefix, this is insufficient to get lib/qsastime/tai-utc-gen and co for the cross build.
> 
> I attached the log from the last build on Linux/aarch64, but you can also find the logs online at Azure [1]. Note that I can run the Linux builds with QEMU if cross-compiling is not possible (it is just very slow), but I can't use hardware emulation for the MacOS/arm64 host.
> 
> Any pointers, tips or tricks are much appreciated.
> 
> All the best
> Sebastian
> 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] Native build problems when cross-compiling PLplot

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

Hi Sebastian,

Alan informed me about earlier experiences with cross-compilation. I copy his answer below:

===
Hi Arjen:

Andrew Ross got cross-compilation to work (with some limitations) back in 2009.  I suggest if you haven't done so already you review that mailing list thread (which you can find with a subject line search for "cross compilation" in the plplot_devel mailing list archive at SF).

Andrew commented in that thread that he had documented some of his cross-compilation experiences in our old wiki.  All the contents of that old wiki were transferred to our SF wiki back when I established that SF wiki so his (dated) documentation/comments about cross-compilation should be accessible at our SF wiki.  Indeed, if you search there, there are 7 wiki pages that mention "cross" so if you follow up on those hits (which I did not) I assume you will find what Andrew (and others?) wrote about cross compilation back in 2009 or so.

Of course, if you make some modern progress with cross-compilation, please update the SF wiki accordingly following the wiki update procedure in README.developers.

Cheers,

Alan
===

I have not had time yet to look into this information or the mailing list's archive.

Regards,

Arjen



-----Original Message-----
From: Sebastian Ehlert <aw...@gm...>
Sent: 24 February 2022 12:15
To: plp...@li...
Subject: [Plplot-devel] Native build problems when cross-compiling PLplot

Hi everybody,

I'm currently trying to cross-compile PLplot for Linux/ppc64le,
Linux/aarch64 and MacOS/arm64 using the conda-forge toolchain [1].

[1]:https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fconda-forge%2Fplplot-feedstock%2Fpull%2F1&amp;data=04%7C01%7C%7C2ffc86b57cc94f978ced08d9f787029c%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C637812981507864811%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=NP%2F81%2BvuCTVIY6lONGAiDo%2Ff6BKxJVemV0s%2F2hO%2BP%2BU%3D&amp;reserved=0

>From the PLplot wiki [2] I figured I need a native build first, to get access to some intermediary binaries, which are than used in a cross build done in a second step. However, getting the native build running in the cross environment is giving me some grief. Linking lib/qsastime/tai-utc-gen in the native build fails for me because I can't get CMake to *not* find and *not* prefer the sysroot of cross- compiler (pc_libplplot_LINK_FLAGS is including the libm for the host platform).

[2]:https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fplplot%2Fwiki%2FBuilding_PLplot_with_a_cross-compiler%2F&amp;data=04%7C01%7C%7C2ffc86b57cc94f978ced08d9f787029c%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C637812981507864811%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=ygGiPYPnsA57l4xNzMut1kuit6QcmWOgADzapiNu2F4%3D&amp;reserved=0

What I can't do is have two different environments here (native first and cross later), because I run inside conda-build to make the packaging automatic with the conda-forge toolchain for future PLplot releases. While I can install a native PLplot version and point to its prefix, this is insufficient to get lib/qsastime/tai-utc-gen and co for the cross build.

I attached the log from the last build on Linux/aarch64, but you can also find the logs online at Azure [1]. Note that I can run the Linux builds with QEMU if cross-compiling is not possible (it is just very slow), but I can't use hardware emulation for the MacOS/arm64 host.

Any pointers, tips or tricks are much appreciated.

All the best
Sebastian
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-devel] Native build problems when cross-compiling PLplot

[Sebastian E. <aw...@gm...>]

Hi everybody,

I'm currently trying to cross-compile PLplot for Linux/ppc64le,
Linux/aarch64 and MacOS/arm64 using the conda-forge toolchain [1].

[1]:https://github.com/conda-forge/plplot-feedstock/pull/1

>From the PLplot wiki [2] I figured I need a native build first, to get
access to some intermediary binaries, which are than used in a cross
build done in a second step. However, getting the native build running
in the cross environment is giving me some grief. Linking
lib/qsastime/tai-utc-gen in the native build fails for me because I
can't get CMake to *not* find and *not* prefer the sysroot of cross-
compiler (pc_libplplot_LINK_FLAGS is including the libm for the host
platform).

[2]:https://sourceforge.net/p/plplot/wiki/Building_PLplot_with_a_cross-compiler/

What I can't do is have two different environments here (native first
and cross later), because I run inside conda-build to make the
packaging automatic with the conda-forge toolchain for future PLplot
releases. While I can install a native PLplot version and point to its
prefix, this is insufficient to get lib/qsastime/tai-utc-gen and co for
the cross build.

I attached the log from the last build on Linux/aarch64, but you can
also find the logs online at Azure [1]. Note that I can run the Linux
builds with QEMU if cross-compiling is not possible (it is just very
slow), but I can't use hardware emulation for the MacOS/arm64 host.

Any pointers, tips or tricks are much appreciated.

All the best
Sebastian

Re: [Plplot-devel] Cross-compilation of PLplot

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

Hi Alan,

Thanks for this information - I will look up these pages (and forward this information to Sebastian 😉).

Regards,

Arjen

-----Original Message-----
From: Alan W. Irwin <Ala...@gm...>
Sent: 23 February 2022 21:50
To: Arjen Markus <Arj...@de...>
Cc: PLplot development list <plp...@li...>
Subject: Re: [Plplot-devel] Cross-compilation of PLplot

On 2022-02-23 07:23-0000 Arjen Markus wrote:

> Hi,
>
> Sebastian Ehlert asked me about cross-compilation of PLplot for different platforms as part of cond-forge/plplot-feedstock. He found out that this needs to be done in two steps, one to build the auxiliary programs for use on the native platform and the second for the actual cross-compilation. Does anyone have experience with this? What procedure would you recommend? Is there an easy way to make this build scenario easier?

Hi Arjen:

Andrew Ross got cross-compilation to work (with some limitations) back in 2009.  I suggest if you haven't done so already you review that mailing list thread (which you can find with a subject line search for "cross compilation" in the plplot_devel mailing list archive at SF).

Andrew commented in that thread that he had documented some of his cross-compilation experiences in our old wiki.  All the contents of that old wiki were transferred to our SF wiki back when I established that SF wiki so his (dated) documentation/comments about cross-compilation should be accessible at our SF wiki.  Indeed, if you search there, there are 7 wiki pages that mention "cross" so if you follow up on those hits (which I did not) I assume you will find what Andrew (and others?) wrote about cross compilation back in 2009 or so.

Of course, if you make some modern progress with cross-compilation, please update the SF wiki accordingly following the wiki update procedure in README.developers.

Cheers,

Alan

__________________________
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy, University of Victoria, Victoria, BC, Canada.

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.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________
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] Cross-compilation of PLplot

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

On 2022-02-23 07:23-0000 Arjen Markus wrote:

> Hi,
>
> Sebastian Ehlert asked me about cross-compilation of PLplot for different platforms as part of cond-forge/plplot-feedstock. He found out that this needs to be done in two steps, one to build the auxiliary programs for use on the native platform and the second for the actual cross-compilation. Does anyone have experience with this? What procedure would you recommend? Is there an easy way to make this build scenario easier?

Hi Arjen:

Andrew Ross got cross-compilation to work (with some limitations) back
in 2009.  I suggest if you haven't done so already you review that
mailing list thread (which you can find with a subject line search for
"cross compilation" in the plplot_devel mailing list archive at SF).

Andrew commented in that thread that he had documented some of his
cross-compilation experiences in our old wiki.  All the contents of
that old wiki were transferred to our SF wiki back when I established
that SF wiki so his (dated) documentation/comments about
cross-compilation should be accessible at our SF wiki.  Indeed, if you
search there, there are 7 wiki pages that mention "cross" so if you
follow up on those hits (which I did not) I assume you will find what
Andrew (and others?) wrote about cross compilation back in 2009 or so.

Of course, if you make some modern progress with cross-compilation,
please update the SF wiki accordingly following the wiki update
procedure in README.developers.

Cheers,

Alan

__________________________
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

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.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-devel] Cross-compilation of PLplot

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

Hi,

Sebastian Ehlert asked me about cross-compilation of PLplot for different platforms as part of cond-forge/plplot-feedstock. He found out that this needs to be done in two steps, one to build the auxiliary programs for use on the native platform and the second for the actual cross-compilation. Does anyone have experience with this? What procedure would you recommend? Is there an easy way to make this build scenario easier?

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] The Debian PLplot fails

[Rafael L. <ra...@la...>]

* Rafael Laboissière <ra...@la...> [2021-11-03 16:17]:
>
> At any rate, I could fix the SIP-based PyQt bindings compilation in 
> Debian, by adding the following to 
> bindings/qt_gui/pyqt5/pyproject.toml:
>
>    [tool.sip.project]
>    sip-files-dir = "."
>    sip-include-dirs = ["/usr/lib/python3/dist-packages/PyQt5/bindings"]
>
> This may be a bug in the sip-tools package in Debian and not actually 
> in PLplot.

Let me just add a comment about the solution above that I am currently 
implementing in the Debian package for PLplot.

 From the point of view of building the plplot package, what 
changed between versions 6.1.1 and 6.3.1 of SIP is the fact that the 
PLplot support for SIP/PyQt detects /usr/bin/sip-build as 
SIPBUILD_EXECUTABLE in the later but not in the former. This prevents the 
execution of the CMake code around the variable PYQT_SIP_DIR. This 
variable was previously used in the call "${SIP_EXECUTABLE} [...] 
-I${PYQT_SIP_DIR}" in bindings/qt_gui/pyqt5/CMakeLists.txt.

Now, with SIP 6.3.1, /usr/bin/sip-build is used instead of /usr/bin/sip 
and the path for QtCore/QtCoremod.sip must be inserted into the file 
bindings/qt_gui/pyqt5/pyproject.toml (hence my solution). Note that I 
hardcoded the path in the sip-include-dirs configuration variable. This 
should be done by substituting the value inside pyproject.toml.

My knowledge of CMake is too limited and I am afraid I cannot propose a 
working solution any soon.  However, with the diagnosis above, I think 
that the PLplot developers can work a proper implementation out.

Best,

Rafael Laboissière

Re: [Plplot-devel] The Debian PLplot fails

[Rafael L. <ra...@la...>]

Hi Orion,

Thank you for the link Orion. I suspect that the sip packages in Debian 
and Fedora differ in their setup.

At any rate, I could fix the SIP-based PyQt bindings compilation in 
Debian, by adding the following to bindings/qt_gui/pyqt5/pyproject.toml:

     [tool.sip.project]
     sip-files-dir = "."
     sip-include-dirs = ["/usr/lib/python3/dist-packages/PyQt5/bindings"]

This may be a bug in the sip-tools package in Debian and not actually in 
PLplot.

Best,

Rafael

* Orion Poplawski <or...@nw...> [2021-11-02 11:05]:

> On 11/2/21 10:40, Rafael Laboissière wrote:
>> * Orion Poplawski <or...@nw...> [2021-10-30 16:32]:
>>>
>>> So, it appears that the Fedora plplot package is building fine with sip 
>>> 6.3.1.  Perhaps you may find some clues there, though I'm not sure we 
>>> re-generate the bindings in our builds.
>>
>> Are the Fedora build logs available somewhere. I mean, like in Debian: 
>> https://buildd.debian.org/status/package.php?p=plplot
>>
>> Best,
>>
>> Rafael Laboissière
>
> https://koji.fedoraproject.org/koji/packageinfo?packageID=3493
>
> -- 
> Orion Poplawski
> IT Systems Manager                         720-772-5637
> NWRA, Boulder/CoRA Office             FAX: 303-415-9702
> 3380 Mitchell Lane                       or...@nw...
> Boulder, CO 80301                 https://www.nwra.com/




> _______________________________________________ 
> Plplot-devel mailing list 
> Plp...@li... 
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] The Debian PLplot fails

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

On 11/2/21 10:40, Rafael Laboissière wrote:
> * Orion Poplawski <or...@nw...> [2021-10-30 16:32]:
>>
>> So, it appears that the Fedora plplot package is building fine with sip
>> 6.3.1.  Perhaps you may find some clues there, though I'm not sure we
>> re-generate the bindings in our builds.
> 
> Are the Fedora build logs available somewhere. I mean, like in Debian:
> https://buildd.debian.org/status/package.php?p=plplot
> 
> Best,
> 
> Rafael Laboissière

https://koji.fedoraproject.org/koji/packageinfo?packageID=3493

-- 
Orion Poplawski
IT Systems Manager                         720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

Re: [Plplot-devel] The Debian PLplot fails

[Rafael L. <ra...@la...>]

* Orion Poplawski <or...@nw...> [2021-10-30 16:32]:
>
> So, it appears that the Fedora plplot package is building fine with 
> sip 6.3.1.  Perhaps you may find some clues there, though I'm not sure 
> we re-generate the bindings in our builds.

Are the Fedora build logs available somewhere. I mean, like in Debian: 
https://buildd.debian.org/status/package.php?p=plplot

Best,

Rafael Laboissière

Re: [Plplot-devel] The Debian PLplot fails

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

On 10/30/21 15:38, Alan W. Irwin wrote:
> On 2021-10-30 20:33+0100 António Rodrigues Tomé wrote:
> 
>> Hi Alan
>> I do not know if I will be able to solve in short/medium time whatever 
>> the
>> problem is as I usually do not use python or  pyqt. So I will try to 
>> learn
>> what this is all about.
> 
> Thanks for being willing to take this on.  Sip (which is how we
> generate our pyqt bindings) advertises itself as a really easy-to-use
> method of generating such bindings.  So by consulting that sip
> documentation page (referenced in my recent email), you might be able
> to very quickly figure out what to do for the latest sip version.
> 
> If/when you get modern sip to generate our pyqt5 binding by hand, I
> would be happy to help with any CMake-related adjustments that need to
> be made.  For example, I have just discovered that "sip -V" generates
> the sip version string which would allow me to create a simple CMake
> test for the sip version.  That test would allow us to use the present
> method for old sip versions and any new method you figure out for
> later sip versions.

So, it appears that the Fedora plplot package is building fine with sip 
6.3.1.  Perhaps you may find some clues there, though I'm not sure we 
re-generate the bindings in our builds.

-- 
Orion Poplawski
he/him/his - surely the least important thing about me
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

Re: [Plplot-devel] The Debian PLplot fails

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

On 2021-10-30 20:33+0100 António Rodrigues Tomé wrote:

> Hi Alan
> I do not know if I will be able to solve in short/medium time whatever the
> problem is as I usually do not use python or  pyqt. So I will try to learn
> what this is all about.

Thanks for being willing to take this on.  Sip (which is how we
generate our pyqt bindings) advertises itself as a really easy-to-use
method of generating such bindings.  So by consulting that sip
documentation page (referenced in my recent email), you might be able
to very quickly figure out what to do for the latest sip version.

If/when you get modern sip to generate our pyqt5 binding by hand, I
would be happy to help with any CMake-related adjustments that need to
be made.  For example, I have just discovered that "sip -V" generates
the sip version string which would allow me to create a simple CMake
test for the sip version.  That test would allow us to use the present
method for old sip versions and any new method you figure out for
later sip versions.

Cheers,

Alan

__________________________
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

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.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] The Debian PLplot fails

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

Hi Alan
I do not know if I will be able to solve in short/medium time whatever the
problem is as I usually do not use python or  pyqt. So I will try to learn
what this is all about.

cheers

On Sat, Oct 30, 2021 at 7:18 PM Alan W. Irwin <Ala...@gm...>
wrote:

> On 2021-10-30 07:26+0200 Rafael Laboissière wrote:
>
> > Yes, [-DENABLE_pyqt5=OFF] is the simplest way to get the package
> building without issues.
> > However, from the point of view of the Debian distribution, this means
> that
> > python3-plplot-qt should be dropped from the list of binary packages
> built
> > from the plplot source package.  This change that we have to tweak the
> > package and, then, once uploaded, it will have to go through the NEW
> queue
> > [*], in order to get the approval of the ftp-masters. Finally, when the
> > PyQt/SIP issues will be fixed in the future, then we will have to tweak
> back
> > the changes, reintroduce python3-plplot-qt and the package will have to
> got
> > through the NEW queue again.
> >
> > I would rather prefer to wait until the issue is fixed upstream. There
> is no
> > rush for that, because the next release of Debian stable will not happen
> any
> > soon (the latest release was done this year and the Debian release life
> cycle
> > is two years).
>
> To Rafael and António:
>
> @Rafael:
> It sounds like your "wait and see" strategy (instead of changing the
> package and putting it through the NEW queue potentially twice) is the
> right way to go.
>
> @both:
>
> I am not happy with how riverbankcomputing keeps breaking things for
> sip users with no explicit documentation of the breakage (as far as
> I could tell with my google searches, see yesterday's post).
>
> @António:
> If you prefer not to fix this season's breakage with the prospect of
> having to do it again every few years, then I would strongly lean
> toward removing our pyqt binding and example completely just to make
> our upstream life (and downstream packaging life) easier.
>
> Cheers,
>
> Alan
> __________________________
> Alan W. Irwin
>
> Research affiliation with the Department of Physics and Astronomy,
> University of Victoria, Victoria, BC, Canada.
>
> 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.org); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>


-- 

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-devel] The Debian PLplot fails

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

On 2021-10-30 07:26+0200 Rafael Laboissière wrote:

> Yes, [-DENABLE_pyqt5=OFF] is the simplest way to get the package building without issues. 
> However, from the point of view of the Debian distribution, this means that 
> python3-plplot-qt should be dropped from the list of binary packages built 
> from the plplot source package.  This change that we have to tweak the 
> package and, then, once uploaded, it will have to go through the NEW queue 
> [*], in order to get the approval of the ftp-masters. Finally, when the 
> PyQt/SIP issues will be fixed in the future, then we will have to tweak back 
> the changes, reintroduce python3-plplot-qt and the package will have to got 
> through the NEW queue again.
>
> I would rather prefer to wait until the issue is fixed upstream. There is no 
> rush for that, because the next release of Debian stable will not happen any 
> soon (the latest release was done this year and the Debian release life cycle 
> is two years).

To Rafael and António:

@Rafael:
It sounds like your "wait and see" strategy (instead of changing the
package and putting it through the NEW queue potentially twice) is the
right way to go.

@both:

I am not happy with how riverbankcomputing keeps breaking things for
sip users with no explicit documentation of the breakage (as far as
I could tell with my google searches, see yesterday's post).

@António: 
If you prefer not to fix this season's breakage with the prospect of
having to do it again every few years, then I would strongly lean
toward removing our pyqt binding and example completely just to make
our upstream life (and downstream packaging life) easier.

Cheers,

Alan
__________________________
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

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.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] The Debian PLplot fails

[Rafael L. <ra...@la...>]

* Alan W. Irwin <Ala...@gm...> [2021-10-29 13:44]:

> On 2021-10-29 13:42+0200 Rafael Laboissière wrote:
>
>> The Debian plplot package is failing to build against version 6.3.1 
>> of sip-tools. The latest correct build of the package was done 
>> against sit-tools 6.1.1.¹
>>
>> This issue has been reported in Bug#997739.²
>>
>> This bug is tagged "serious". I could not find a way to fix it. If 
>> it is not fixed, then the plplot package will be removed from Debian 
>> testing and, consequently, from the next Debian release.
>
> My impression is our pyqt bindings have *always* been precarious 
> because of the rather large sip churn, and this issue seems to be 
> another example of that.

This is my impression too.

> I assume that our Qt developer, António Tomé, will eventually be able 
> to find a way to build our pyqt5 bindings against sip 6.3.1, but that 
> will likely take a while since sip is not very good (in my experience) 
> at documenting what their churn is and how to adjust to it.

Yes, let us hope it.

> Meanwhile, there is absolutely no need for packagers like yourself to 
> give up on PLplot because one minor component of it does not build 
> against new versions of libraries/tools.  Instead, simply use (in this case) 
> -DENABLE_pyqt5=OFF, and it should build and run without issues.

Yes, this is the simplest way to get the package building without issues. 
However, from the point of view of the Debian distribution, this means 
that python3-plplot-qt should be dropped from the list of binary packages 
built from the plplot source package.  This change that we have to tweak 
the package and, then, once uploaded, it will have to go through the NEW 
queue [*], in order to get the approval of the ftp-masters. Finally, when 
the PyQt/SIP issues will be fixed in the future, then we will have to 
tweak back the changes, reintroduce python3-plplot-qt and the package 
will have to got through the NEW queue again.

I would rather prefer to wait until the issue is fixed upstream. There is 
no rush for that, because the next release of Debian stable will not 
happen any soon (the latest release was done this year and the Debian 
release life cycle is two years).

Best,

Rafael

[*] https://ftp-master.debian.org/new.html

Re: [Plplot-devel] The Debian PLplot fails

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

On 2021-10-29 13:44-0700 Alan W. Irwin wrote:

> [...]I assume that our Qt developer, António
> Tomé, will eventually be able to find a way to build our pyqt5
> bindings against sip 6.3.1, but that will likely take a while since
> sip is not very good (in my experience) at documenting what their
> churn is and how to adjust to it.

To expand on that comment, google searches for sip are obfuscated
by other (telephony) software called sip which has nothing to do with
the sip we need.  Therefore, I just did a number of google searches
using site:riverbankcomputing.com (since that company is the author of
the sip we need), and I could find no mention of sip release notes.
I did find [sip
documentation](https://www.riverbankcomputing.com/static/Docs/sip/index.html)
which might help António find a solution (even though this documentation
is for 6.4, and I could find no riverbankcomputing documentation for earlier
versions of sip!)

Alan
__________________________
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

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.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] The Debian PLplot fails

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

On 2021-10-29 13:42+0200 Rafael Laboissière wrote:

> Dear PLplot developers,
>
> The Debian plplot package is failing to build against version 6.3.1 of 
> sip-tools. The latest correct build of the package was done against sit-tools 
> 6.1.1.¹
>
> This issue has been reported in Bug#997739.²
>
> This bug is tagged "serious". I could not find a way to fix it. If it is not 
> fixed, then the plplot package will be removed from Debian testing and, 
> consequently, from the next Debian release.

Hi Rafael:

Thanks for reporting this build issue against a new version of sip tools.

My impression is our pyqt bindings have *always* been precarious
because of the rather large sip churn, and this issue seems to be
another example of that.  I assume that our Qt developer, António
Tomé, will eventually be able to find a way to build our pyqt5
bindings against sip 6.3.1, but that will likely take a while since
sip is not very good (in my experience) at documenting what their
churn is and how to adjust to it.

Meanwhile, there is absolutely no need for packagers like yourself to
give up on PLplot because one minor component of it does not build
against new versions of libraries/tools.  Instead, simply use (in this case)
-DENABLE_pyqt5=OFF, and it should build and run without issues.

Cheers,

Alan
__________________________
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

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.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-devel] The Debian PLplot fails

[Rafael L. <ra...@la...>]

Dear PLplot developers,

The Debian plplot package is failing to build against version 6.3.1 of 
sip-tools. The latest correct build of the package was done against 
sit-tools 6.1.1.¹

This issue has been reported in Bug#997739.²

This bug is tagged "serious". I could not find a way to fix it. If it is 
not fixed, then the plplot package will be removed from Debian testing 
and, consequently, from the next Debian release.

Best,

Rafael Laboissière

  ¹ https://buildd.debian.org/status/fetch.php?pkg=plplot&arch=amd64&ver=5.15.0%2Bdfsg-22&stamp=1629132352&raw=0
  ² https://bugs.debian.org/997739

Re: [Plplot-devel] plplot qt driver deprecated functions

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

Hi António:

Based on the testing information you supplied I have now pushed your
commit (with revised commit message but no other changes).  See <https://sourceforge.net/p/plplot/plplot/ci/6a12ffe24060803e1d66ae457fa7663dc4ded5bf/>.

On 2021-08-04 11:33+0100 António Rodrigues Tomé wrote:

> And for qt6 I kind hijacked the qt5 optins and just  replaced the
> conditions for qt5 with the ones for qt6
> cmake/modules/qt.cmake
>
> and some of the
> CMakeLists.txt
>
> CMakeLists.txt
> bindings/qt_gui/CMakeLists.txt
> examples/c++/CMakeLists.txt
> src/CMakeLists.txt

> [...O]ne must decide if to keep two distinct options choose qt5
> or qt5 or let the system decide what to use.
> [...C]hanges were very slim. most of them were replacing QT5:: by Qt6::
> but for the qt.cmake that I also attach

I will likely implement a default of looking first for Qt6 then Qt5
(if the build system cannot find Qt6) but with an option for
knowledgeable users to force one or the other.

It will probably be several months until I can get to this (and it
will also be after I completely strip out Qt4), but based on the above
extremely useful information from you I think I now know what needs to
be done to fully support both Qt5 and Qt6 with our build system.

Cheers,

Alan
__________________________
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

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.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] plplot qt driver deprecated functions

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

On 2021-08-03 12:20+0100 António Rodrigues Tomé wrote:

> Hi Alan
>
> I was able to build the plplot using qt6.1 and found out that there were
> other classes (the 2D transformation Matrix class) that were dropped in
> qt6. So I made a small patch replacing that class and some others minor
> changes with function members that became deprecated in qt 6.0
>
> I've tested it in my default qt 5.15 and in the latest qt6.1.2  version.
> Everything looks to work very fine.
> So I think that when the time is right one can face without any worries the
> transition from qt5 to qt6 without the need to use the Core5Compat package.

Hi António:

Thanks for this next step in future-proofing PLplot for the Qt6 case.

For your commit I built the test_all_qt target without issues for my Debian Stable
Qt5.11 case so I am ready to push your commit as soon as you can
clarify (for the associated commit message) how you tested it with
both Qt5 and Qt6.

What method did you use to build our qt-related components for the Qt6 case
since our build system is not currently ready for Qt6?  For example, did
you build all those PLplot components by hand?

And for both the Qt5 and Qt6 cases did you build the test_all_qt
target or did you use some other method to run-time test your commit?

It is going to be a while until I can do this, but obviously my next
Qt-related step here is to strip out all Qt4 from our build system
(which will greatly simplify builds of our Qt-related components
because builds against Qt4 use ancient CMake methods while builds
against later Qt versions use quite different and much more powerful
modern CMake methods).

Also considering the problem of supporting both Qt5 and Qt6 I will need
more information from you.  For example, how far do you get with
the following change to line 144 of cmake/modules/qt.cmake and
using -DENABLE_pyqt5=OFF (since pyqt5 is unlikely to work with Qt6).

- find_package(Qt5 5.7.1 COMPONENTS Svg Gui PrintSupport Widgets)
+ find_package(Qt6 6.1.2 COMPONENTS Svg Gui PrintSupport Widgets)
+ # temporary workaround
+ set(Qt5_FOUND Qt6_FOUND)

please capture the stdout and stderr output from cmake and make using

cmake <usual options including -DENABLE_pyqt5=OFF and pathname for top directory of source-tree> >& cmake.out
# Only if cmake works
make VERBOSE=1 test_all_qt >& test_all_qt.out

and send those *.out files to me.

Alan
__________________________
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

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.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] plplot qt driver deprecated functions

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

Hi Alan

I was able to build the plplot using qt6.1 and found out that there were
other classes (the 2D transformation Matrix class) that were dropped in
qt6. So I made a small patch replacing that class and some others minor
changes with function members that became deprecated in qt 6.0

I've tested it in my default qt 5.15 and in the latest qt6.1.2  version.
Everything looks to work very fine.
So I think that when the time is right one can face without any worries the
transition from qt5 to qt6 without the need to use the Core5Compat package.

cheers



On Thu, Jul 8, 2021 at 12:26 AM Alan W. Irwin <Ala...@gm...>
wrote:

> On 2021-07-06 23:34+0100 António Rodrigues Tomé wrote:
>
> > [... I built] all the examples and the patch i send you now seems to work
> > very fine:
>
> Same here so I pushed it.  See
> <
> https://sourceforge.net/p/plplot/plplot/ci/cf04f2e6b555edab673a9703cea909d7239ce21b/
> >
> for the substantially changed commit message that includes details of
> the tests I ran.
>
> Thanks very much for getting this revised version of your commit to work
> without generating
> the segfaults produced by the prior version.
>
> > P.s. Latter on I will try to understand how to deploy  pyqt5_example.
>
> The missing Python library issue that was previously stopping you can
> obviously be addressed by installing the right opensuse package.  But
> finding the name of that needed package is more "an art rather than a
> science".
>
> To help you with that "art" here are the equivalent details on my
> Debian Stable platform.
>
> # Find the names of all packages which include a partial filename
> "libplplot*.so$"
> # where ".so" with nothing further added is important since it is that
> exact suffix the linker looks for.
> irwin@merlin> apt-file search libpython |grep '\.so$' |less
>
> There were 17 different possibilities, but one of those
>
> libpython3.7-dev: /usr/lib/x86_64-linux-gnu/libpython3.7m.so
>
> referred to the development version of libpython3 so I am sure
> that is the library that is needed, and I do have that package
> already installed.  So I think this
> result for Debian Stable means you need to install the development
> version of either the python3 or libpython3 package (depending on how
> opensuse organizes its package names and designates the name of the
> development version of those).  Of course, opensuse will not have
> the apt-file application, but it should have something equivalent so
> that you can associate filenames with the packages (either installed
> or not installed) that include those files.
>
> After a successful build I confirmed that /usr/lib/x86_64-linux-gnu/
> libpython3.7m.so name as follows:
>
> # Find the exact name of that library (at least for Debian Stable after a
> successful build
> of the python binding):
>
> software@merlin> readelf -d bindings/python/_plplotc.so |grep -E
> 'PATH|NEEDED'
>   0x0000000000000001 (NEEDED)             Shared library: [libplplot.so.17]
>   0x0000000000000001 (NEEDED)             Shared library:
> [libpython3.7m.so.1.0]
>   0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>   0x000000000000001d (RUNPATH)            Library runpath:
> [/home/software/plplot/HEAD/build_dir/src:]
>
> Hope this working Debian Stable example helps you figure out what to do
> for opensuse to gain
> access to that distro's python3 library.
>
> > also going to try to see how i can force plplot to build with qt6 and
> then
> > one will know if this small patch is enough to deal with the next major
> > version of the qt,
>
> Good luck implementing these important Qt6-ready goals for PLplot.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Research affiliation with the Department of Physics and Astronomy,
> University of Victoria, Victoria, BC, Canada.
>
> 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.org); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>


-- 

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