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.