You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(14) |
Jun
(1) |
Jul
(3) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(16) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(13) |
Feb
(22) |
Mar
(7) |
Apr
(8) |
May
(8) |
Jun
(11) |
Jul
(2) |
Aug
|
Sep
(5) |
Oct
(31) |
Nov
(23) |
Dec
(3) |
2002 |
Jan
(1) |
Feb
(17) |
Mar
(10) |
Apr
(3) |
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
(11) |
Oct
(5) |
Nov
(21) |
Dec
(20) |
2003 |
Jan
(27) |
Feb
(13) |
Mar
(20) |
Apr
(11) |
May
(12) |
Jun
(7) |
Jul
(16) |
Aug
(21) |
Sep
(9) |
Oct
(28) |
Nov
(24) |
Dec
(30) |
2004 |
Jan
(31) |
Feb
(5) |
Mar
|
Apr
(8) |
May
(12) |
Jun
(7) |
Jul
(13) |
Aug
(12) |
Sep
(2) |
Oct
(14) |
Nov
(42) |
Dec
(14) |
2005 |
Jan
|
Feb
|
Mar
(20) |
Apr
(17) |
May
(9) |
Jun
|
Jul
(7) |
Aug
(3) |
Sep
(17) |
Oct
(14) |
Nov
(9) |
Dec
|
2006 |
Jan
|
Feb
|
Mar
(13) |
Apr
(2) |
May
(46) |
Jun
(2) |
Jul
(20) |
Aug
(26) |
Sep
(31) |
Oct
(5) |
Nov
(9) |
Dec
(13) |
2007 |
Jan
(24) |
Feb
(22) |
Mar
(13) |
Apr
(25) |
May
(25) |
Jun
(9) |
Jul
(20) |
Aug
(9) |
Sep
(26) |
Oct
(3) |
Nov
(4) |
Dec
(3) |
2008 |
Jan
(92) |
Feb
(35) |
Mar
(39) |
Apr
(15) |
May
|
Jun
|
Jul
(18) |
Aug
(5) |
Sep
(5) |
Oct
(7) |
Nov
(10) |
Dec
(27) |
2009 |
Jan
(35) |
Feb
(34) |
Mar
(13) |
Apr
(9) |
May
(18) |
Jun
(9) |
Jul
(15) |
Aug
(13) |
Sep
(64) |
Oct
(7) |
Nov
(43) |
Dec
|
2010 |
Jan
(75) |
Feb
(22) |
Mar
(44) |
Apr
(34) |
May
(47) |
Jun
(77) |
Jul
(28) |
Aug
(7) |
Sep
(45) |
Oct
(1) |
Nov
(19) |
Dec
(7) |
2011 |
Jan
(14) |
Feb
|
Mar
(6) |
Apr
(12) |
May
(19) |
Jun
(3) |
Jul
(8) |
Aug
(4) |
Sep
(3) |
Oct
(21) |
Nov
(11) |
Dec
(4) |
2012 |
Jan
(2) |
Feb
(9) |
Mar
|
Apr
(1) |
May
(2) |
Jun
|
Jul
(1) |
Aug
(5) |
Sep
(5) |
Oct
(1) |
Nov
(18) |
Dec
(2) |
2013 |
Jan
(15) |
Feb
(16) |
Mar
(8) |
Apr
(5) |
May
|
Jun
(1) |
Jul
(17) |
Aug
(3) |
Sep
(17) |
Oct
(43) |
Nov
(25) |
Dec
(9) |
2014 |
Jan
(4) |
Feb
(8) |
Mar
(20) |
Apr
(14) |
May
(49) |
Jun
(1) |
Jul
|
Aug
(18) |
Sep
(2) |
Oct
(1) |
Nov
(22) |
Dec
(3) |
2015 |
Jan
(41) |
Feb
(2) |
Mar
(34) |
Apr
(30) |
May
(14) |
Jun
(17) |
Jul
(29) |
Aug
(3) |
Sep
(3) |
Oct
(1) |
Nov
(7) |
Dec
(4) |
2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
(4) |
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
(25) |
Oct
(9) |
Nov
(14) |
Dec
(13) |
2017 |
Jan
(11) |
Feb
(8) |
Mar
(12) |
Apr
(4) |
May
(25) |
Jun
(2) |
Jul
|
Aug
(5) |
Sep
(10) |
Oct
(25) |
Nov
|
Dec
(6) |
2018 |
Jan
(18) |
Feb
(6) |
Mar
(6) |
Apr
(1) |
May
(7) |
Jun
(13) |
Jul
(8) |
Aug
|
Sep
(5) |
Oct
(2) |
Nov
(17) |
Dec
(3) |
2019 |
Jan
(11) |
Feb
(4) |
Mar
(13) |
Apr
(19) |
May
(1) |
Jun
(2) |
Jul
(8) |
Aug
(4) |
Sep
(32) |
Oct
(51) |
Nov
(1) |
Dec
(9) |
2020 |
Jan
(9) |
Feb
(6) |
Mar
|
Apr
|
May
(3) |
Jun
(2) |
Jul
(5) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(7) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(3) |
Dec
|
2022 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <iri...@ir...> - 2024-02-21 23:01:20
|
I'd like to do CRT terminal graphics on my Raspberry Pi 5 and really don't know were to start. Will PlPlot output graphics to my Pi 5 screen to show graphics? Has anyone successfully done this? George W. J. Kenney, Jr. Retired Synthetic Organic Chemist Retired Industrial Analytical Chemist Retired Eastman Kodak Chemist Retired Real Time S/W Engineer Fully-Retired Professor of Chemistry Avid Cyclist, Diver, Kayaker, Pilot, Student of Marshal Arts and Tennis The Irishman <mailto:Irishman@IrishmanSoftware.com> Irishman@IrishmanSoftware.com |
From: Spong, D. <sp...@or...> - 2022-07-26 21:01:36
|
I recently updated my Plplot to version 5.15.0 due to problems I was having with earlier versions. I have tried it with one of my Plplot-enabled Fortran codes. It compiles okay, but when I try to run the code, I get the following error. Any suggestions as to what is causing this and how I should fix it? xplot dyld: Symbol not found: _for__b_fmt_table Referenced from: /Users/dsp/fortran_code_development/AE_eigenmode_code/SOURCE_codes/xplot Expected in: /usr/local/lib/libplplotfortran.0.dylib in /Users/dsp/fortran_code_development/AE_eigenmode_code/SOURCE_codes/xplot zsh: abort Thanks, Don _________________________________________________________ Donald A. Spong, Fusion Energy Theory, ORNL One Bethel Valley Road, Bldg. 7601 P. O. Box 2008, Room 239 Oak Ridge, Tennessee 37831-6305 Phone: (865) 574-1304 FAX: (865) 576-7926 E-mail: sp...@or... _________________________________________________________ |
From: <koi...@ya...> - 2022-01-19 01:27:07
|
Hi Anan, Thank you very much for your quick response, and for the detailed information you kindly sent me. After reading through PLplot document I realized that my first email was not very clear and might have confused you. Let me show my code first: ######################################### # CODE STARTS FROM HERE (FORTRAN) ######################################### subroutine plplot_contour(lclab,ccol,clskip,clspace,cthick,shedge,xg,yg,zg) implicit none logical , intent(in) :: lclab integer(4) , intent(in) :: ccol, clskip real(8) , intent(in) :: clspace real(8) , intent(in) :: cthick real(8) , intent(in) :: shedge(:) real(8) , intent(in) :: xg(:), yg(:), zg(:,:) ! work integer(4) :: nxc, nyc integer(4) :: i, nshedge, sigdig nxc = size(zg,1) nyc = size(zg,2) nshedge = size(shedge) call plcol0(ccol) call plwidth(cthick) do i=1, nshedge if( shedge(i)>=0 )then ! solid line call pllsty(1) else ! broken line call pllsty(2) endif if( lclab .and. mod(i-1,clskip)==1 )then ! with label call pl_setcontlabelparam( 0.01D0, 0.6D0, clspace, 1) else ! without label call pl_setcontlabelparam( 0.01D0, 0.6D0, clspace, 0) endif sigdig = numsigdig( shedge(i) ) call pl_setcontlabelformat(4,sigdig) call plcont( zg , 1, nxc, 1, nyc, & & (/shedge(i)/), xg, yg ) enddo end subroutine plplot_contour ############################################################ # CODE ENDS HERE (Many thanks again for supporting FORTRAN!) ############################################################ This is a FORTRAN code which takes a 2-dimentional array and plot it with plcont, where I also use pl_setccontlabelparam to specify how far contour labels stand "off lines". In this specific case, I suppose that the best example would be Demo09-01: http://plplot.org/examples.php?demo=09 , , and I tried to ask if countour labels could be placed in line-break, e,g, : https://docs.generic-mapping-tools.org/6.3/gallery/ex13.html. Shozee > ----- Original Message ----- > > From: "Alan W. Irwin" <Ala...@gm...> > To: "koi...@ya..." <koi...@ya...> > Cc: "plp...@li..." <plp...@li...> > Date: 2022/01/18 火 13:32 > Subject: Re: [Plplot-general] Line break for plcont > > > On 2022-01-18 12:19+0900 koi...@ya... wrote: > > [...] > > There is one option I wish I could have in plplot: making a linebreak to put labels in between. > > > > To be precise, there may be two options. One is, make a line, put a white box on the line, then put numbers in. > > > > The other option is, literally break a line (draw two lines with some space) and put numbers in between. > > > > (Both look good to me). > > > > > > > > > > Hopefully anyone can spare some time to consider adding it or tell me how ? > > Hi Shozee: > > I am answering you on the assumption your subject line should have been "line break for PLplot" > since you did not mention plcont anywhere inside your email. > > If that assumption is correct I suggest you take a look at pllegend > which was designed to give users tremendous control over how text (and > graphics) are arranged within a legend (within a plot). Of course, > that enormous capability makes its API complex, but check the > [documentation of that > API](http://plplot.org/docbook-manual/plplot-html-5.15.0/pllegend.html) > to see whether that API might provide exactly what you need. That API > is demonstrated in a simplistic way in [example > 4](http://plplot.org/examples.php?demo=04) and [example > 26](http://plplot.org/examples.php?demo=26) which are useful to show > how to turn everything off other than the small subset of that API > that you need. That API is demonstrated in a more comprehensive way > in [example 33](http://plplot.org/examples.php?demo=33). > > Good luck and let us know how it goes! > > 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 > __________________________ > |
From: Alan W. I. <Ala...@gm...> - 2022-01-18 04:45:21
|
On 2022-01-18 12:19+0900 koi...@ya... wrote: [...] > There is one option I wish I could have in plplot: making a linebreak to put labels in between. > > To be precise, there may be two options. One is, make a line, put a white box on the line, then put numbers in. > > The other option is, literally break a line (draw two lines with some space) and put numbers in between. > > (Both look good to me). > > > > > Hopefully anyone can spare some time to consider adding it or tell me how ? Hi Shozee: I am answering you on the assumption your subject line should have been "line break for PLplot" since you did not mention plcont anywhere inside your email. If that assumption is correct I suggest you take a look at pllegend which was designed to give users tremendous control over how text (and graphics) are arranged within a legend (within a plot). Of course, that enormous capability makes its API complex, but check the [documentation of that API](http://plplot.org/docbook-manual/plplot-html-5.15.0/pllegend.html) to see whether that API might provide exactly what you need. That API is demonstrated in a simplistic way in [example 4](http://plplot.org/examples.php?demo=04) and [example 26](http://plplot.org/examples.php?demo=26) which are useful to show how to turn everything off other than the small subset of that API that you need. That API is demonstrated in a more comprehensive way in [example 33](http://plplot.org/examples.php?demo=33). Good luck and let us know how it goes! 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 __________________________ |
From: <koi...@ya...> - 2022-01-18 03:19:54
|
* { font-size: 13px; font-family: 'MS Pゴシック', sans-serif;}p, ul, ol, blockquote { margin: 0;}a { color: #0064c8; text-decoration: none;}a:hover { color: #0057af; text-decoration: underline;}a:active { color: #004c98;} Hello, everone. I am currently developing an interactive plotter that does some number-crunching and shows results with plplot. First of all, I thank all the developers for making this beautiful software available to us. The simple APIs with the perfect document let my small project quickly shape up. There is one option I wish I could have in plplot: making a linebreak to put labels in between. To be precise, there may be two options. One is, make a line, put a white box on the line, then put numbers in. The other option is, literally break a line (draw two lines with some space) and put numbers in between. (Both look good to me). Hopefully anyone can spare some time to consider adding it or tell me how ? Shozee |
From: R S. <s...@sr...> - 2021-11-15 17:41:06
|
Very helpful. Appreciate your explanations. Thanks, srini On Sun, Nov 14, 2021 at 8:00 PM Alan W. Irwin <Ala...@gm...> wrote: > On 2021-11-14 15:00-0500 R Srinivasan wrote: > > > Newbie here. Using PlPlot bindings of Ada. > > > > I am trying to create 2 plots to fit on the same page - as in the Real > and > > Imaginary components of a complex signal. > > > > When I use the png output - only the first plot is ever seen. Same with > jpg > > outputs. On the other hand, when pdf output is used 2 different pages are > > in the file and they contain the 2 plots. > > > > Example 2a appears to do something similar and the results are as > outlined > > above. > > > > My platform is Windows with mingw64 > > > > Clues appreciated. Thanks, Srini > > Hi Srini: > > First some background. > > In general (i.e., this is an external requirement) some graphics > file types (e.g, PNG, JPEG) don't allow multiple pages while others > (e.g. PDF) do allow multiple pages. > > PLplot works around that external issue for modern file device drivers > by providing an option to generate separate files for each multiple > page. This concept is called familied files, and for more details > about that please look at > < > http://plplot.org/docbook-manual/plplot-html-5.15.0/devices.html#familying > >. > > By the way, for the PNG format I would highly recommend using either > the pngcairo device or the pnqqt device. If you build your own PLplot > those devices should be available for MSYS2 (which fully supports the > cairo and Qt libraries which those devices depend on). On the other > hand, I would not recommend using the png device since that is > deprecated. > > I think that backgrounds answers why you are getting different paging > results for different devices. But to answer your specific question, > it appears you are trying to generate separate plots for a single page > (e.g., like <http://plplot.org/examples.php?demo=01>), and my guess is > you ran into the paging difficulties because of some mistake in your > code (e.g., forgetting to call plstar) that generated multiple pages > rather than just your desired single page with multiple plots. > Anyhow, if that is the case, please take a look at that example to see > what to do for the multiple plot per page case. > > 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 > __________________________ > |
From: Alan W. I. <Ala...@gm...> - 2021-11-15 01:00:51
|
On 2021-11-14 15:00-0500 R Srinivasan wrote: > Newbie here. Using PlPlot bindings of Ada. > > I am trying to create 2 plots to fit on the same page - as in the Real and > Imaginary components of a complex signal. > > When I use the png output - only the first plot is ever seen. Same with jpg > outputs. On the other hand, when pdf output is used 2 different pages are > in the file and they contain the 2 plots. > > Example 2a appears to do something similar and the results are as outlined > above. > > My platform is Windows with mingw64 > > Clues appreciated. Thanks, Srini Hi Srini: First some background. In general (i.e., this is an external requirement) some graphics file types (e.g, PNG, JPEG) don't allow multiple pages while others (e.g. PDF) do allow multiple pages. PLplot works around that external issue for modern file device drivers by providing an option to generate separate files for each multiple page. This concept is called familied files, and for more details about that please look at <http://plplot.org/docbook-manual/plplot-html-5.15.0/devices.html#familying>. By the way, for the PNG format I would highly recommend using either the pngcairo device or the pnqqt device. If you build your own PLplot those devices should be available for MSYS2 (which fully supports the cairo and Qt libraries which those devices depend on). On the other hand, I would not recommend using the png device since that is deprecated. I think that backgrounds answers why you are getting different paging results for different devices. But to answer your specific question, it appears you are trying to generate separate plots for a single page (e.g., like <http://plplot.org/examples.php?demo=01>), and my guess is you ran into the paging difficulties because of some mistake in your code (e.g., forgetting to call plstar) that generated multiple pages rather than just your desired single page with multiple plots. Anyhow, if that is the case, please take a look at that example to see what to do for the multiple plot per page case. 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 __________________________ |
From: R S. <s...@sr...> - 2021-11-14 20:58:16
|
Newbie here. Using PlPlot bindings of Ada. I am trying to create 2 plots to fit on the same page - as in the Real and Imaginary components of a complex signal. When I use the png output - only the first plot is ever seen. Same with jpg outputs. On the other hand, when pdf output is used 2 different pages are in the file and they contain the 2 plots. Example 2a appears to do something similar and the results are as outlined above. My platform is Windows with mingw64 Clues appreciated. Thanks, Srini |
From: Alan W. I. <Ala...@gm...> - 2021-10-31 19:47:15
|
Hi Sergey: Please CC list since PLplot questions/answers are of some interest to all users (including those in the future who are looking at list archives for answers). On 2021-10-31 20:18+0200 Sergey Shcherbina wrote: > > Dear Alan, > > Your last letter helped us how to solve a problem with PLplot. > > I think it just was a problem with Ubuntu. I changed Ubuntu to > > Fedora - Linux fedora 5.14.14-200.fc34.x86_64 and now no technical > > problems with using your PLplot software. Good. > We have simple question: > > what function PLplot should be used for changing the quantity of > > the tick labels and ticks on 2D or 3D plots? plbox and plbox3 which are documented at <http://plplot.org/docbook-manual/plplot-html-5.15.0/plbox.html> and and <http://plplot.org/docbook-manual/plplot-html-5.15.0/plbox3.html>. 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 __________________________ |
From: Alan W. I. <Ala...@gm...> - 2021-10-28 22:42:29
|
On 2021-10-28 18:31+0300 Sergey Shcherbina wrote: > Hi all! > > We worked with plplot many years without any problems. Now we used compiled x16c.c for testing of it in a new > > area: Linux 5.4.0-89-generic #100~18.04.1-Ubuntu SMP Wed Sep 29 10:59:42 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux > > What we have after starting compiled x16c.c: > > Plotting Options: > < 1> ps PostScript File (monochrome) > < 2> psc PostScript File (color) > < 3> xfig Fig file > < 4> null Null device > < 5> mem User-supplied memory device > < 6> wxwidgets wxWidgets Driver > < 7> svg Scalable Vector Graphics (SVG 1.1) > < 8> bmpqt Qt Windows bitmap driver > < 9> jpgqt Qt jpg driver > <10> pngqt Qt png driver > <11> ppmqt Qt ppm driver > <12> tiffqt Qt tiff driver > <13> svgqt Qt SVG driver > <14> qtwidget Qt Widget > <15> pdfqt Qt PDF driver > <16> extqt External Qt driver > <17> memqt Memory Qt driver > > Enter device number or keyword: ??? > > We use plspal0( "cmap0_black_on_white.pal" ) and plspal1( "cmap1_gray.pal", 1 ) for plotting device definitions as you proposed. > > What should be added in the compilation options for solving this problem? It worked without these questions before last OS changing. > > Our compilaton options: > > /usr/bin/gcc -Wall `pkg-config --cflags --libs plplot` -I/usr/local/include/gsl -c $1 > /usr/bin/gcc -L/usr/lib ./$FirstOfile `pkg-config --cflags --libs plplot` -lgsl -lgslcblas -lm $(mysql_config --libs) -o ... Please include more details in your report such as the PLplot version currently not working for you; its provenance (e.g., is it from an installed Ubuntu package, a version you built and installed yourself, etc.); exact details of the build of your x16c application (e.g., expand $1 and $FirstOfile above, and give the generated executable name); and exactly how you ran (e.g., include all command-line options) that built executable. Also, what version (and provenance) of PLplot worked for you before? Note, if there is some PLplot packaging error with Ubuntu we cannot help you very much. However, we can help you if you build and install Plplot yourself from either the latest release (5.15.0) or ideally the git master tip version. For example, such installs include C examples (such as x16c) that are all ready to build using pkg-config, and also include tests of such pkg-config-based builds. N.B. we continue to maintain our installed pkg-config-based build and test system for our standard examples, and if you have found a bug in that, we will fix it. However, that build and test system is quite low power and therefore we recommend instead our high-power CMake-based build and test system for our installed examples. See <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/> for further details about our various test systems. 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 __________________________ |
From: Alan W. I. <Ala...@gm...> - 2021-07-13 01:52:16
|
It is my pleasure to announce publicly that António Rodrigues Tomé has just become an official member of the PLplot core development team. (For a list of all official members of that team, see <https://sourceforge.net/p/plplot/_members/>.) António's primary development interest in PLplot is in that software's Qt5 related components, and he plans further changes (if necessary) for PLplot to make it compatible with Qt6 as well. It's great to have that Qt maintenance expertise on our core team because our Qt-related components provide some of our best-looking plots. However, I also encourage António to work on more than just the Qt-related components of PLplot if he spots anything else he would like to improve. Welcome, António! 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 mailing list Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Arjen M. <Arj...@de...> - 2021-05-18 12:30:34
|
Hi Kay-Uwe, I did not realise it could this simple 😉. We/I should have a look at this feature. Regards, Arjen From: Kirstein, Kay-Uwe <kay...@us...> Sent: 18 May 2021 12:55 To: Arjen Markus <Arj...@de...>; plp...@li... Subject: AW: Cross-compiling in Cygwin Hi Arjen, here is a kind of “minimalistic” toolchain file, I used successfully for cross-compiling from Cygwin to native Windows: set(CMAKE_SYSTEM_NAME Windows) set(CMAKE_C_COMPILER /usr/bin/x86_64-w64-mingw32-gcc) To enable bindings to other languages like C++ and Fortran, the respective cross-compilers might be also set. Hope this helps, Kay-Uwe Von: Arjen Markus <Arj...@de...<mailto:Arj...@de...>> Gesendet: Freitag, 14. Mai 2021 10:28 An: Kirstein, Kay-Uwe <kay...@us...<mailto:kay...@us...>>; plp...@li...<mailto:plp...@li...> Betreff: RE: Cross-compiling in Cygwin Hi Kay-Uwe, I have updated the links in this wiki page. Do you have an eample of that toolchain file, so that we can update the page further? Regards, Arjen From: Kirstein, Kay-Uwe <kay...@us...<mailto:kay...@us...>> Sent: 12 May 2021 17:13 To: Arjen Markus <Arj...@de...<mailto:Arj...@de...>>; plp...@li...<mailto:plp...@li...> Subject: AW: Cross-compiling in Cygwin Hi Arjen, in the meantime I found out that cross-compiling mode of cmake was not correctly enabled. It looks like one explicitly need a toolchain file with CMAKE_SYSTEM_NAME set. After doing so, cross-compiling PLplot works like a charm! Maybe, one could add an example toolchain file in the wiki (https://sourceforge.net/p/plplot/wiki/Building_PLplot_with_a_cross-compiler/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fplplot%2Fwiki%2FBuilding_PLplot_with_a_cross-compiler%2F&data=04%7C01%7C%7Cb8801addf4484fb5e3ff08d919eb725a%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C0%7C637569321299414977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2JD6ex1DQzaz9xtg1B%2B%2Fw8ymO1q%2Ff%2BWLV6gPwehJ6V8%3D&reserved=0>) as the link to the cmake docs seems to be outdated. Sorry for bothering! Best regards, Kay-Uwe Von: Kirstein, Kay-Uwe Gesendet: Mittwoch, 12. Mai 2021 15:39 An: Arjen Markus <Arj...@de...<mailto:Arj...@de...>>; plp...@li...<mailto:plp...@li...> Betreff: AW: Cross-compiling in Cygwin Hi Arjen, thanks for your fast answer. Using a cross-compiling scheme was my first natural choice as the MinGW-w64 toolchain I am using is located in my Cygwin environment and the generated PLplot libs should be also located there (there is a different sys-root for native Windows stuff, not relying on Cygwin.dll). The MinGW-tools themselves rely on the Linux-style path names, but any executable generated by them, e.g., tai-utc-gen.exe expect Windows-style path names. Anyway, I will try to perform a native Windows build outside of Cygwin, but I might need another version of the MinGW-w64 toolchain as you are pointing out. Best regards, Kay-Uwe Von: Arjen Markus <Arj...@de...<mailto:Arj...@de...>> Gesendet: Mittwoch, 12. Mai 2021 08:40 An: Kirstein, Kay-Uwe <kay...@us...<mailto:kay...@us...>>; plp...@li...<mailto:plp...@li...> Betreff: RE: Cross-compiling in Cygwin Hi Kay-Uwe, I have never tried this cross-compilation, but your observation about the paths not being recognized does ring a bell. MinGW-w64/MSYS2 (to call it by its most descriptive name) comes with two environments, one very Linux-like, and therefore compatible with Cygwin in its style of path identification and one that is more Windows-like and therefore uses a Windows-style of path identification. (Don’t pin me down though on the details – they always confuse me) That said, I do not have a solution/workaround for the problem. But do you really need to cross-compile? Regards, Arjen From: Kirstein, Kay-Uwe <kay...@us...<mailto:kay...@us...>> Sent: 12 May 2021 08:06 To: plp...@li...<mailto:plp...@li...> Subject: [Plplot-general] Cross-compiling in Cygwin Hello, I am trying to build PLplot on Windows. As I have a Cygwin environment and want to build for (native) Mingw, used the cross-compiling scheme as described on the Wiki (https://sourceforge.net/p/plplot/wiki/Building_PLplot_with_a_cross-compiler/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fplplot%2Fwiki%2FBuilding_PLplot_with_a_cross-compiler%2F&data=04%7C01%7C%7Cb8801addf4484fb5e3ff08d919eb725a%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C0%7C637569321299414977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2JD6ex1DQzaz9xtg1B%2B%2Fw8ymO1q%2Ff%2BWLV6gPwehJ6V8%3D&reserved=0>) and mailing list (https://sourceforge.net/p/plplot/mailman/plplot-general/thread/alpine.DEB.2.11.1710051507310.4357%40enira.zlyna.ubzr/#msg36065593<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fplplot%2Fmailman%2Fplplot-general%2Fthread%2Falpine.DEB.2.11.1710051507310.4357%2540enira.zlyna.ubzr%2F%23msg36065593&data=04%7C01%7C%7Cb8801addf4484fb5e3ff08d919eb725a%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C0%7C637569321299424927%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=P07iG%2B7iJ%2FYasBh5ko%2BRJ2VHi2qJSS9atBTKxMsJUn8%3D&reserved=0>). So I started with a Cygwin build: mkdir build_cygwin cd build_cygwin cmake -DCMAKE_C_COMPILER=gcc ../PLplot make all which works fine. Then a made a new build folder for the Mingw build: mkdir build_mingw cd build_mingw cmake -DCMAKE_C_COMPILER=x86_64-w64-mingw32-gcc -DCMAKE_INSTALL_PREFIX=/usr/x86_64-w64-mingw32/sys-root/mingw -DCMAKE_NATIVE_BINARY_DIR=../build_cygwin ../PLplot make all It fails with the following message: [ 8%] Generating tai-utc.h Cannot open first file as readable make[2]: *** [lib/qsastime/CMakeFiles/tai-utc.h_built.dir/build.make:74: lib/qsastime/tai-utc.h] Fehler 1 make[1]: *** [CMakeFiles/Makefile2:869: lib/qsastime/CMakeFiles/tai-utc.h_built.dir/all] Fehler 2 make: *** [Makefile:156: all] Fehler 2 It looks like that tai-utc-gen.exe, which is now build with Mingw toolchain cannot deal with the given Cygwin-style path parameter. In cross-compiling mode, I would have expected that the either the needed header files are copied from the native build or the generator executables are taken from there. When I manually copy the generated header files (./lib/qsatime/tai-utc.h ./lib/qsatime/deltaT.h and ./include/plhershey-unicode.h) from build_cygwin to build_mingw, the build continues successfully. An interesting observation is that during configure of the Mingw build, cmake reports an unused variable CMAKE_NATIVE_BINARY_DIR. I played around with setting CMAKE_CROSSCOMPILING=TRUE or moving CMAKE_C_COMPILER= x86_64-w64-mingw32-gcc to a toolchain file, which is called via CMAKE_TOOLCHAIN_FILE=toolchain.cmake with no difference. Am I missing something here? Any help is greatly appreciated. Best regards, Kay-Uwe Kirstein DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. 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. |
From: Kirstein, Kay-U. <kay...@us...> - 2021-05-18 10:55:51
|
Hi Arjen, here is a kind of "minimalistic" toolchain file, I used successfully for cross-compiling from Cygwin to native Windows: set(CMAKE_SYSTEM_NAME Windows) set(CMAKE_C_COMPILER /usr/bin/x86_64-w64-mingw32-gcc) To enable bindings to other languages like C++ and Fortran, the respective cross-compilers might be also set. Hope this helps, Kay-Uwe Von: Arjen Markus <Arj...@de...> Gesendet: Freitag, 14. Mai 2021 10:28 An: Kirstein, Kay-Uwe <kay...@us...>; plp...@li... Betreff: RE: Cross-compiling in Cygwin Hi Kay-Uwe, I have updated the links in this wiki page. Do you have an eample of that toolchain file, so that we can update the page further? Regards, Arjen From: Kirstein, Kay-Uwe <kay...@us...> Sent: 12 May 2021 17:13 To: Arjen Markus <Arj...@de...>; plp...@li... Subject: AW: Cross-compiling in Cygwin Hi Arjen, in the meantime I found out that cross-compiling mode of cmake was not correctly enabled. It looks like one explicitly need a toolchain file with CMAKE_SYSTEM_NAME set. After doing so, cross-compiling PLplot works like a charm! Maybe, one could add an example toolchain file in the wiki (https://sourceforge.net/p/plplot/wiki/Building_PLplot_with_a_cross-compiler/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fplplot%2Fwiki%2FBuilding_PLplot_with_a_cross-compiler%2F&data=04%7C01%7C%7Cc6976dd4d6614fd9d3e708d91558748b%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C637564291932298631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TESGDWCPYUtC657YND7FdP8blWu6D%2FladWX6JiwR2FU%3D&reserved=0>) as the link to the cmake docs seems to be outdated. Sorry for bothering! Best regards, Kay-Uwe Von: Kirstein, Kay-Uwe Gesendet: Mittwoch, 12. Mai 2021 15:39 An: Arjen Markus <Arj...@de...<mailto:Arj...@de...>>; plp...@li...<mailto:plp...@li...> Betreff: AW: Cross-compiling in Cygwin Hi Arjen, thanks for your fast answer. Using a cross-compiling scheme was my first natural choice as the MinGW-w64 toolchain I am using is located in my Cygwin environment and the generated PLplot libs should be also located there (there is a different sys-root for native Windows stuff, not relying on Cygwin.dll). The MinGW-tools themselves rely on the Linux-style path names, but any executable generated by them, e.g., tai-utc-gen.exe expect Windows-style path names. Anyway, I will try to perform a native Windows build outside of Cygwin, but I might need another version of the MinGW-w64 toolchain as you are pointing out. Best regards, Kay-Uwe Von: Arjen Markus <Arj...@de...<mailto:Arj...@de...>> Gesendet: Mittwoch, 12. Mai 2021 08:40 An: Kirstein, Kay-Uwe <kay...@us...<mailto:kay...@us...>>; plp...@li...<mailto:plp...@li...> Betreff: RE: Cross-compiling in Cygwin Hi Kay-Uwe, I have never tried this cross-compilation, but your observation about the paths not being recognized does ring a bell. MinGW-w64/MSYS2 (to call it by its most descriptive name) comes with two environments, one very Linux-like, and therefore compatible with Cygwin in its style of path identification and one that is more Windows-like and therefore uses a Windows-style of path identification. (Don't pin me down though on the details - they always confuse me) That said, I do not have a solution/workaround for the problem. But do you really need to cross-compile? Regards, Arjen From: Kirstein, Kay-Uwe <kay...@us...<mailto:kay...@us...>> Sent: 12 May 2021 08:06 To: plp...@li...<mailto:plp...@li...> Subject: [Plplot-general] Cross-compiling in Cygwin Hello, I am trying to build PLplot on Windows. As I have a Cygwin environment and want to build for (native) Mingw, used the cross-compiling scheme as described on the Wiki (https://sourceforge.net/p/plplot/wiki/Building_PLplot_with_a_cross-compiler/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fplplot%2Fwiki%2FBuilding_PLplot_with_a_cross-compiler%2F&data=04%7C01%7C%7Cc6976dd4d6614fd9d3e708d91558748b%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C637564291932308584%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uAzt5cKlme6CJNWGzqGygJV%2BgfXnJuu8Pl4eSE5B8Rk%3D&reserved=0>) and mailing list (https://sourceforge.net/p/plplot/mailman/plplot-general/thread/alpine.DEB.2.11.1710051507310.4357%40enira.zlyna.ubzr/#msg36065593<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fplplot%2Fmailman%2Fplplot-general%2Fthread%2Falpine.DEB.2.11.1710051507310.4357%2540enira.zlyna.ubzr%2F%23msg36065593&data=04%7C01%7C%7Cc6976dd4d6614fd9d3e708d91558748b%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C637564291932308584%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OjvsPjlnPD4zUqeBc0qw%2FHXo7loomKFUHGuJVsFm8zc%3D&reserved=0>). So I started with a Cygwin build: mkdir build_cygwin cd build_cygwin cmake -DCMAKE_C_COMPILER=gcc ../PLplot make all which works fine. Then a made a new build folder for the Mingw build: mkdir build_mingw cd build_mingw cmake -DCMAKE_C_COMPILER=x86_64-w64-mingw32-gcc -DCMAKE_INSTALL_PREFIX=/usr/x86_64-w64-mingw32/sys-root/mingw -DCMAKE_NATIVE_BINARY_DIR=../build_cygwin ../PLplot make all It fails with the following message: [ 8%] Generating tai-utc.h Cannot open first file as readable make[2]: *** [lib/qsastime/CMakeFiles/tai-utc.h_built.dir/build.make:74: lib/qsastime/tai-utc.h] Fehler 1 make[1]: *** [CMakeFiles/Makefile2:869: lib/qsastime/CMakeFiles/tai-utc.h_built.dir/all] Fehler 2 make: *** [Makefile:156: all] Fehler 2 It looks like that tai-utc-gen.exe, which is now build with Mingw toolchain cannot deal with the given Cygwin-style path parameter. In cross-compiling mode, I would have expected that the either the needed header files are copied from the native build or the generator executables are taken from there. When I manually copy the generated header files (./lib/qsatime/tai-utc.h ./lib/qsatime/deltaT.h and ./include/plhershey-unicode.h) from build_cygwin to build_mingw, the build continues successfully. An interesting observation is that during configure of the Mingw build, cmake reports an unused variable CMAKE_NATIVE_BINARY_DIR. I played around with setting CMAKE_CROSSCOMPILING=TRUE or moving CMAKE_C_COMPILER= x86_64-w64-mingw32-gcc to a toolchain file, which is called via CMAKE_TOOLCHAIN_FILE=toolchain.cmake with no difference. Am I missing something here? Any help is greatly appreciated. Best regards, Kay-Uwe Kirstein DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Arjen M. <Arj...@de...> - 2021-05-14 12:05:23
|
Hi Kay-Uwe, I have updated the links in this wiki page. Do you have an eample of that toolchain file, so that we can update the page further? Regards, Arjen From: Kirstein, Kay-Uwe <kay...@us...> Sent: 12 May 2021 17:13 To: Arjen Markus <Arj...@de...>; plp...@li... Subject: AW: Cross-compiling in Cygwin Hi Arjen, in the meantime I found out that cross-compiling mode of cmake was not correctly enabled. It looks like one explicitly need a toolchain file with CMAKE_SYSTEM_NAME set. After doing so, cross-compiling PLplot works like a charm! Maybe, one could add an example toolchain file in the wiki (https://sourceforge.net/p/plplot/wiki/Building_PLplot_with_a_cross-compiler/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fplplot%2Fwiki%2FBuilding_PLplot_with_a_cross-compiler%2F&data=04%7C01%7C%7Cc6976dd4d6614fd9d3e708d91558748b%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C637564291932298631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TESGDWCPYUtC657YND7FdP8blWu6D%2FladWX6JiwR2FU%3D&reserved=0>) as the link to the cmake docs seems to be outdated. Sorry for bothering! Best regards, Kay-Uwe Von: Kirstein, Kay-Uwe Gesendet: Mittwoch, 12. Mai 2021 15:39 An: Arjen Markus <Arj...@de...<mailto:Arj...@de...>>; plp...@li...<mailto:plp...@li...> Betreff: AW: Cross-compiling in Cygwin Hi Arjen, thanks for your fast answer. Using a cross-compiling scheme was my first natural choice as the MinGW-w64 toolchain I am using is located in my Cygwin environment and the generated PLplot libs should be also located there (there is a different sys-root for native Windows stuff, not relying on Cygwin.dll). The MinGW-tools themselves rely on the Linux-style path names, but any executable generated by them, e.g., tai-utc-gen.exe expect Windows-style path names. Anyway, I will try to perform a native Windows build outside of Cygwin, but I might need another version of the MinGW-w64 toolchain as you are pointing out. Best regards, Kay-Uwe Von: Arjen Markus <Arj...@de...<mailto:Arj...@de...>> Gesendet: Mittwoch, 12. Mai 2021 08:40 An: Kirstein, Kay-Uwe <kay...@us...<mailto:kay...@us...>>; plp...@li...<mailto:plp...@li...> Betreff: RE: Cross-compiling in Cygwin Hi Kay-Uwe, I have never tried this cross-compilation, but your observation about the paths not being recognized does ring a bell. MinGW-w64/MSYS2 (to call it by its most descriptive name) comes with two environments, one very Linux-like, and therefore compatible with Cygwin in its style of path identification and one that is more Windows-like and therefore uses a Windows-style of path identification. (Don't pin me down though on the details - they always confuse me) That said, I do not have a solution/workaround for the problem. But do you really need to cross-compile? Regards, Arjen From: Kirstein, Kay-Uwe <kay...@us...<mailto:kay...@us...>> Sent: 12 May 2021 08:06 To: plp...@li...<mailto:plp...@li...> Subject: [Plplot-general] Cross-compiling in Cygwin Hello, I am trying to build PLplot on Windows. As I have a Cygwin environment and want to build for (native) Mingw, used the cross-compiling scheme as described on the Wiki (https://sourceforge.net/p/plplot/wiki/Building_PLplot_with_a_cross-compiler/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fplplot%2Fwiki%2FBuilding_PLplot_with_a_cross-compiler%2F&data=04%7C01%7C%7Cc6976dd4d6614fd9d3e708d91558748b%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C637564291932308584%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uAzt5cKlme6CJNWGzqGygJV%2BgfXnJuu8Pl4eSE5B8Rk%3D&reserved=0>) and mailing list (https://sourceforge.net/p/plplot/mailman/plplot-general/thread/alpine.DEB.2.11.1710051507310.4357%40enira.zlyna.ubzr/#msg36065593<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fplplot%2Fmailman%2Fplplot-general%2Fthread%2Falpine.DEB.2.11.1710051507310.4357%2540enira.zlyna.ubzr%2F%23msg36065593&data=04%7C01%7C%7Cc6976dd4d6614fd9d3e708d91558748b%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C637564291932308584%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OjvsPjlnPD4zUqeBc0qw%2FHXo7loomKFUHGuJVsFm8zc%3D&reserved=0>). So I started with a Cygwin build: mkdir build_cygwin cd build_cygwin cmake -DCMAKE_C_COMPILER=gcc ../PLplot make all which works fine. Then a made a new build folder for the Mingw build: mkdir build_mingw cd build_mingw cmake -DCMAKE_C_COMPILER=x86_64-w64-mingw32-gcc -DCMAKE_INSTALL_PREFIX=/usr/x86_64-w64-mingw32/sys-root/mingw -DCMAKE_NATIVE_BINARY_DIR=../build_cygwin ../PLplot make all It fails with the following message: [ 8%] Generating tai-utc.h Cannot open first file as readable make[2]: *** [lib/qsastime/CMakeFiles/tai-utc.h_built.dir/build.make:74: lib/qsastime/tai-utc.h] Fehler 1 make[1]: *** [CMakeFiles/Makefile2:869: lib/qsastime/CMakeFiles/tai-utc.h_built.dir/all] Fehler 2 make: *** [Makefile:156: all] Fehler 2 It looks like that tai-utc-gen.exe, which is now build with Mingw toolchain cannot deal with the given Cygwin-style path parameter. In cross-compiling mode, I would have expected that the either the needed header files are copied from the native build or the generator executables are taken from there. When I manually copy the generated header files (./lib/qsatime/tai-utc.h ./lib/qsatime/deltaT.h and ./include/plhershey-unicode.h) from build_cygwin to build_mingw, the build continues successfully. An interesting observation is that during configure of the Mingw build, cmake reports an unused variable CMAKE_NATIVE_BINARY_DIR. I played around with setting CMAKE_CROSSCOMPILING=TRUE or moving CMAKE_C_COMPILER= x86_64-w64-mingw32-gcc to a toolchain file, which is called via CMAKE_TOOLCHAIN_FILE=toolchain.cmake with no difference. Am I missing something here? Any help is greatly appreciated. Best regards, Kay-Uwe Kirstein DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Kirstein, Kay-U. <kay...@us...> - 2021-05-12 15:13:36
|
Hi Arjen, in the meantime I found out that cross-compiling mode of cmake was not correctly enabled. It looks like one explicitly need a toolchain file with CMAKE_SYSTEM_NAME set. After doing so, cross-compiling PLplot works like a charm! Maybe, one could add an example toolchain file in the wiki (https://sourceforge.net/p/plplot/wiki/Building_PLplot_with_a_cross-compiler/) as the link to the cmake docs seems to be outdated. Sorry for bothering! Best regards, Kay-Uwe Von: Kirstein, Kay-Uwe Gesendet: Mittwoch, 12. Mai 2021 15:39 An: Arjen Markus <Arj...@de...>; plp...@li... Betreff: AW: Cross-compiling in Cygwin Hi Arjen, thanks for your fast answer. Using a cross-compiling scheme was my first natural choice as the MinGW-w64 toolchain I am using is located in my Cygwin environment and the generated PLplot libs should be also located there (there is a different sys-root for native Windows stuff, not relying on Cygwin.dll). The MinGW-tools themselves rely on the Linux-style path names, but any executable generated by them, e.g., tai-utc-gen.exe expect Windows-style path names. Anyway, I will try to perform a native Windows build outside of Cygwin, but I might need another version of the MinGW-w64 toolchain as you are pointing out. Best regards, Kay-Uwe Von: Arjen Markus <Arj...@de...> Gesendet: Mittwoch, 12. Mai 2021 08:40 An: Kirstein, Kay-Uwe <kay...@us...>; plp...@li... Betreff: RE: Cross-compiling in Cygwin Hi Kay-Uwe, I have never tried this cross-compilation, but your observation about the paths not being recognized does ring a bell. MinGW-w64/MSYS2 (to call it by its most descriptive name) comes with two environments, one very Linux-like, and therefore compatible with Cygwin in its style of path identification and one that is more Windows-like and therefore uses a Windows-style of path identification. (Don't pin me down though on the details - they always confuse me) That said, I do not have a solution/workaround for the problem. But do you really need to cross-compile? Regards, Arjen From: Kirstein, Kay-Uwe <kay...@us...> Sent: 12 May 2021 08:06 To: plp...@li... Subject: [Plplot-general] Cross-compiling in Cygwin Hello, I am trying to build PLplot on Windows. As I have a Cygwin environment and want to build for (native) Mingw, used the cross-compiling scheme as described on the Wiki (https://sourceforge.net/p/plplot/wiki/Building_PLplot_with_a_cross-compiler/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fplplot%2Fwiki%2FBuilding_PLplot_with_a_cross-compiler%2F&data=04%7C01%7C%7C5799754a8da548dde6aa08d9150e3049%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C637563972950272988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=48uVqrq4LeHA8%2BT7XHqaYxPruOsIsOJuvTVQwZWRveE%3D&reserved=0>) and mailing list (https://sourceforge.net/p/plplot/mailman/plplot-general/thread/alpine.DEB.2.11.1710051507310.4357%40enira.zlyna.ubzr/#msg36065593<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fplplot%2Fmailman%2Fplplot-general%2Fthread%2Falpine.DEB.2.11.1710051507310.4357%2540enira.zlyna.ubzr%2F%23msg36065593&data=04%7C01%7C%7C5799754a8da548dde6aa08d9150e3049%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C637563972950282943%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=Jyy8V45v9T9FB8cbUlgACAUyJrERgLQfmg3LAV2jGi4%3D&reserved=0>). So I started with a Cygwin build: mkdir build_cygwin cd build_cygwin cmake -DCMAKE_C_COMPILER=gcc ../PLplot make all which works fine. Then a made a new build folder for the Mingw build: mkdir build_mingw cd build_mingw cmake -DCMAKE_C_COMPILER=x86_64-w64-mingw32-gcc -DCMAKE_INSTALL_PREFIX=/usr/x86_64-w64-mingw32/sys-root/mingw -DCMAKE_NATIVE_BINARY_DIR=../build_cygwin ../PLplot make all It fails with the following message: [ 8%] Generating tai-utc.h Cannot open first file as readable make[2]: *** [lib/qsastime/CMakeFiles/tai-utc.h_built.dir/build.make:74: lib/qsastime/tai-utc.h] Fehler 1 make[1]: *** [CMakeFiles/Makefile2:869: lib/qsastime/CMakeFiles/tai-utc.h_built.dir/all] Fehler 2 make: *** [Makefile:156: all] Fehler 2 It looks like that tai-utc-gen.exe, which is now build with Mingw toolchain cannot deal with the given Cygwin-style path parameter. In cross-compiling mode, I would have expected that the either the needed header files are copied from the native build or the generator executables are taken from there. When I manually copy the generated header files (./lib/qsatime/tai-utc.h ./lib/qsatime/deltaT.h and ./include/plhershey-unicode.h) from build_cygwin to build_mingw, the build continues successfully. An interesting observation is that during configure of the Mingw build, cmake reports an unused variable CMAKE_NATIVE_BINARY_DIR. I played around with setting CMAKE_CROSSCOMPILING=TRUE or moving CMAKE_C_COMPILER= x86_64-w64-mingw32-gcc to a toolchain file, which is called via CMAKE_TOOLCHAIN_FILE=toolchain.cmake with no difference. Am I missing something here? Any help is greatly appreciated. Best regards, Kay-Uwe Kirstein 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. |
From: Kirstein, Kay-U. <kay...@us...> - 2021-05-12 13:39:26
|
Hi Arjen, thanks for your fast answer. Using a cross-compiling scheme was my first natural choice as the MinGW-w64 toolchain I am using is located in my Cygwin environment and the generated PLplot libs should be also located there (there is a different sys-root for native Windows stuff, not relying on Cygwin.dll). The MinGW-tools themselves rely on the Linux-style path names, but any executable generated by them, e.g., tai-utc-gen.exe expect Windows-style path names. Anyway, I will try to perform a native Windows build outside of Cygwin, but I might need another version of the MinGW-w64 toolchain as you are pointing out. Best regards, Kay-Uwe Von: Arjen Markus <Arj...@de...> Gesendet: Mittwoch, 12. Mai 2021 08:40 An: Kirstein, Kay-Uwe <kay...@us...>; plp...@li... Betreff: RE: Cross-compiling in Cygwin Hi Kay-Uwe, I have never tried this cross-compilation, but your observation about the paths not being recognized does ring a bell. MinGW-w64/MSYS2 (to call it by its most descriptive name) comes with two environments, one very Linux-like, and therefore compatible with Cygwin in its style of path identification and one that is more Windows-like and therefore uses a Windows-style of path identification. (Don't pin me down though on the details - they always confuse me) That said, I do not have a solution/workaround for the problem. But do you really need to cross-compile? Regards, Arjen From: Kirstein, Kay-Uwe <kay...@us...> Sent: 12 May 2021 08:06 To: plp...@li... Subject: [Plplot-general] Cross-compiling in Cygwin Hello, I am trying to build PLplot on Windows. As I have a Cygwin environment and want to build for (native) Mingw, used the cross-compiling scheme as described on the Wiki (https://sourceforge.net/p/plplot/wiki/Building_PLplot_with_a_cross-compiler/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fplplot%2Fwiki%2FBuilding_PLplot_with_a_cross-compiler%2F&data=04%7C01%7C%7C5799754a8da548dde6aa08d9150e3049%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C637563972950272988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=48uVqrq4LeHA8%2BT7XHqaYxPruOsIsOJuvTVQwZWRveE%3D&reserved=0>) and mailing list (https://sourceforge.net/p/plplot/mailman/plplot-general/thread/alpine.DEB.2.11.1710051507310.4357%40enira.zlyna.ubzr/#msg36065593<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fplplot%2Fmailman%2Fplplot-general%2Fthread%2Falpine.DEB.2.11.1710051507310.4357%2540enira.zlyna.ubzr%2F%23msg36065593&data=04%7C01%7C%7C5799754a8da548dde6aa08d9150e3049%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C637563972950282943%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=Jyy8V45v9T9FB8cbUlgACAUyJrERgLQfmg3LAV2jGi4%3D&reserved=0>). So I started with a Cygwin build: mkdir build_cygwin cd build_cygwin cmake -DCMAKE_C_COMPILER=gcc ../PLplot make all which works fine. Then a made a new build folder for the Mingw build: mkdir build_mingw cd build_mingw cmake -DCMAKE_C_COMPILER=x86_64-w64-mingw32-gcc -DCMAKE_INSTALL_PREFIX=/usr/x86_64-w64-mingw32/sys-root/mingw -DCMAKE_NATIVE_BINARY_DIR=../build_cygwin ../PLplot make all It fails with the following message: [ 8%] Generating tai-utc.h Cannot open first file as readable make[2]: *** [lib/qsastime/CMakeFiles/tai-utc.h_built.dir/build.make:74: lib/qsastime/tai-utc.h] Fehler 1 make[1]: *** [CMakeFiles/Makefile2:869: lib/qsastime/CMakeFiles/tai-utc.h_built.dir/all] Fehler 2 make: *** [Makefile:156: all] Fehler 2 It looks like that tai-utc-gen.exe, which is now build with Mingw toolchain cannot deal with the given Cygwin-style path parameter. In cross-compiling mode, I would have expected that the either the needed header files are copied from the native build or the generator executables are taken from there. When I manually copy the generated header files (./lib/qsatime/tai-utc.h ./lib/qsatime/deltaT.h and ./include/plhershey-unicode.h) from build_cygwin to build_mingw, the build continues successfully. An interesting observation is that during configure of the Mingw build, cmake reports an unused variable CMAKE_NATIVE_BINARY_DIR. I played around with setting CMAKE_CROSSCOMPILING=TRUE or moving CMAKE_C_COMPILER= x86_64-w64-mingw32-gcc to a toolchain file, which is called via CMAKE_TOOLCHAIN_FILE=toolchain.cmake with no difference. Am I missing something here? Any help is greatly appreciated. Best regards, Kay-Uwe Kirstein 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. |
From: Arjen M. <Arj...@de...> - 2021-05-12 07:15:15
|
Hi Kay-Uwe, I have never tried this cross-compilation, but your observation about the paths not being recognized does ring a bell. MinGW-w64/MSYS2 (to call it by its most descriptive name) comes with two environments, one very Linux-like, and therefore compatible with Cygwin in its style of path identification and one that is more Windows-like and therefore uses a Windows-style of path identification. (Don't pin me down though on the details - they always confuse me) That said, I do not have a solution/workaround for the problem. But do you really need to cross-compile? Regards, Arjen From: Kirstein, Kay-Uwe <kay...@us...> Sent: 12 May 2021 08:06 To: plp...@li... Subject: [Plplot-general] Cross-compiling in Cygwin Hello, I am trying to build PLplot on Windows. As I have a Cygwin environment and want to build for (native) Mingw, used the cross-compiling scheme as described on the Wiki (https://sourceforge.net/p/plplot/wiki/Building_PLplot_with_a_cross-compiler/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fplplot%2Fwiki%2FBuilding_PLplot_with_a_cross-compiler%2F&data=04%7C01%7C%7C5799754a8da548dde6aa08d9150e3049%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C637563972950272988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=48uVqrq4LeHA8%2BT7XHqaYxPruOsIsOJuvTVQwZWRveE%3D&reserved=0>) and mailing list (https://sourceforge.net/p/plplot/mailman/plplot-general/thread/alpine.DEB.2.11.1710051507310.4357%40enira.zlyna.ubzr/#msg36065593<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fplplot%2Fmailman%2Fplplot-general%2Fthread%2Falpine.DEB.2.11.1710051507310.4357%2540enira.zlyna.ubzr%2F%23msg36065593&data=04%7C01%7C%7C5799754a8da548dde6aa08d9150e3049%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C637563972950282943%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=Jyy8V45v9T9FB8cbUlgACAUyJrERgLQfmg3LAV2jGi4%3D&reserved=0>). So I started with a Cygwin build: mkdir build_cygwin cd build_cygwin cmake -DCMAKE_C_COMPILER=gcc ../PLplot make all which works fine. Then a made a new build folder for the Mingw build: mkdir build_mingw cd build_mingw cmake -DCMAKE_C_COMPILER=x86_64-w64-mingw32-gcc -DCMAKE_INSTALL_PREFIX=/usr/x86_64-w64-mingw32/sys-root/mingw -DCMAKE_NATIVE_BINARY_DIR=../build_cygwin ../PLplot make all It fails with the following message: [ 8%] Generating tai-utc.h Cannot open first file as readable make[2]: *** [lib/qsastime/CMakeFiles/tai-utc.h_built.dir/build.make:74: lib/qsastime/tai-utc.h] Fehler 1 make[1]: *** [CMakeFiles/Makefile2:869: lib/qsastime/CMakeFiles/tai-utc.h_built.dir/all] Fehler 2 make: *** [Makefile:156: all] Fehler 2 It looks like that tai-utc-gen.exe, which is now build with Mingw toolchain cannot deal with the given Cygwin-style path parameter. In cross-compiling mode, I would have expected that the either the needed header files are copied from the native build or the generator executables are taken from there. When I manually copy the generated header files (./lib/qsatime/tai-utc.h ./lib/qsatime/deltaT.h and ./include/plhershey-unicode.h) from build_cygwin to build_mingw, the build continues successfully. An interesting observation is that during configure of the Mingw build, cmake reports an unused variable CMAKE_NATIVE_BINARY_DIR. I played around with setting CMAKE_CROSSCOMPILING=TRUE or moving CMAKE_C_COMPILER= x86_64-w64-mingw32-gcc to a toolchain file, which is called via CMAKE_TOOLCHAIN_FILE=toolchain.cmake with no difference. Am I missing something here? Any help is greatly appreciated. Best regards, Kay-Uwe Kirstein 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. |
From: Kirstein, Kay-U. <kay...@us...> - 2021-05-12 06:21:11
|
Hello, I am trying to build PLplot on Windows. As I have a Cygwin environment and want to build for (native) Mingw, used the cross-compiling scheme as described on the Wiki (https://sourceforge.net/p/plplot/wiki/Building_PLplot_with_a_cross-compiler/) and mailing list (https://sourceforge.net/p/plplot/mailman/plplot-general/thread/alpine.DEB.2.11.1710051507310.4357%40enira.zlyna.ubzr/#msg36065593). So I started with a Cygwin build: mkdir build_cygwin cd build_cygwin cmake -DCMAKE_C_COMPILER=gcc ../PLplot make all which works fine. Then a made a new build folder for the Mingw build: mkdir build_mingw cd build_mingw cmake -DCMAKE_C_COMPILER=x86_64-w64-mingw32-gcc -DCMAKE_INSTALL_PREFIX=/usr/x86_64-w64-mingw32/sys-root/mingw -DCMAKE_NATIVE_BINARY_DIR=../build_cygwin ../PLplot make all It fails with the following message: [ 8%] Generating tai-utc.h Cannot open first file as readable make[2]: *** [lib/qsastime/CMakeFiles/tai-utc.h_built.dir/build.make:74: lib/qsastime/tai-utc.h] Fehler 1 make[1]: *** [CMakeFiles/Makefile2:869: lib/qsastime/CMakeFiles/tai-utc.h_built.dir/all] Fehler 2 make: *** [Makefile:156: all] Fehler 2 It looks like that tai-utc-gen.exe, which is now build with Mingw toolchain cannot deal with the given Cygwin-style path parameter. In cross-compiling mode, I would have expected that the either the needed header files are copied from the native build or the generator executables are taken from there. When I manually copy the generated header files (./lib/qsatime/tai-utc.h ./lib/qsatime/deltaT.h and ./include/plhershey-unicode.h) from build_cygwin to build_mingw, the build continues successfully. An interesting observation is that during configure of the Mingw build, cmake reports an unused variable CMAKE_NATIVE_BINARY_DIR. I played around with setting CMAKE_CROSSCOMPILING=TRUE or moving CMAKE_C_COMPILER= x86_64-w64-mingw32-gcc to a toolchain file, which is called via CMAKE_TOOLCHAIN_FILE=toolchain.cmake with no difference. Am I missing something here? Any help is greatly appreciated. Best regards, Kay-Uwe Kirstein |
From: Alan W. I. <Ala...@gm...> - 2020-08-25 20:43:11
|
On 2020-08-25 11:04+0200 ronald deslandes wrote: > Hi Alan , 2nd > > it worked perfectly: > gfortran my1stpl.f90 -o my1stpl -I/root/plplot/build_dir/bindings/fortran > /root/plplot/build_dir/bindings/fortran/libplplotfortran.so > > and > env LD_LIBRARY_PATH=/root/plplot/build_dir/bindings/fortran ./my1stp > > I got the first result. Good news, indeed, that you could get this hand-generated build to work. However, in the long term I recommend you make a simple CMake project with your code following what is done (for the CORE_BUILD false case which greatly simplifies the required CMake code) in examples/CMakeLists.txt and examples/fortran/CMakeLists.txt. The way that would work is you independently install PLplot, your simple CMake project finds that install (following what is done in examples/CMakeLists.txt using the find_package(plplot) command) and the CMake code you need to build your example should simply reduce after that find to add_excutable(my1stpl my1stpl.f90) target_link_libraries(my1stpl, PLPLOT::plplotfortran) > Thanks. I will close the Ticket No 50. You are welcome. 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 __________________________ |
From: Alan W. I. <Ala...@gm...> - 2020-08-24 17:45:19
|
On 2020-08-23 11:44+0200 ronald deslandes wrote: > Hello > since some decades I am trying to access functionality for the use of plplot > I am running on Linux Leap15.0 > I am a 75-Dino(saur) still working on Fortran. > Since two weeks I succeed in installing plplot with Cmake and looking at some old mails you exchanged > with some bros, I even succeeded in compiling the examples with DBUILD_TEST=ON. > But excuse that I still feel like in a no-where-land and I do not know what to do. > So I just derived a simple own program I tried to compile but I failed. > Can you help? > > program my1stpl > use plplot > implicit none > real(plflt),dimension(6) :: x,y > real(plflt) :: xmin,ymin,xmax,ymax > x(1)=1 > x(2)=2 > x(3)=3 > x(4)=4 > x(5)=5 > x(6)=6 > y=x*x > write(*,*) y > call plinit() > xmin=1. > ymin=1. > xmax=7. > ymax=40. > call plcol0(1) > call plenv(xmin,xmax,ymin,ymax,0,0) > call pllab('X','Y','MY1ST 2D PLOT') > call plpoin(x,y,8) > call plline(x,y) > call plend() > end program my1stpl > > linux-cj8n:~ # gfortran my1stpl.f90 -o my1stpl /root/plplot/build_dir/lib/csa /root/plplot/build_dir/bindings/fortran > /root/plplot/build_dir/src > my1stpl.f90:2:4: > use plplot > 1 > Fatal Error: Can't open module file ‘plplot.mod’ for reading at (1): No such file or directory > compilation terminated. > linux-cj8n:~ # > > (I found a plplot.mod but it the file appears as music note) Hi Ron: The best place to ask for PLplot help is the plplot-general mailing list which I am CCing my response to. So for further questions I suggest you subscribe to that list (see <https://sourceforge.net/projects/plplot/lists/plplot-general> for directions). Since compiling all the examples with -DBUILD_TEST=ON works for you, you are 99% there, and you should just need a tiny bit more to build and run your own programme against plplot. After your above -DBUILD_TEST=ON test, the needed plplot.mod file should appear in the bindings/fortran subdirectory of the build tree. Here is what the file command says about that file on my own system: irwin@merlin> file ~software/plplot/HEAD/build_dir/bindings/fortran/plplot.mod /home/software/plplot/HEAD/build_dir/bindings/fortran/plplot.mod: gzip compressed data, from Unix, original size 430087 You will likely get something similar on your own Linux system. To tell gfortran where that *.mod file is, use the gfortran -I option. Furthermore, gfortran will need to know the location of the Fortran bindings library. Therefore, I suggest you change the above command to gfortran my1stpl.f90 -o my1stpl -I/root/plplot/build_dir/bindings/fortran /root/plplot/build_dir/bindings/fortran/libplplotfortran.so (You might need to add other -I options for other *.mod files, but I doubt you will need to mention other libraries.) Finally, the run-time loader will also need to know where the library is at run time so assuming the above build works, you would run the resulting command as env LD_LIBRARY_PATH=/root/plplot/build_dir/bindings/fortran ./my1stp Good luck, and please let the mailing list know how it goes with the above suggestions. 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 __________________________ |
From: Peter W. <pet...@gm...> - 2020-08-05 15:18:13
|
Case solved (I think) I just need to link to the z library: -lz Best wishes Peter On Tue, 4 Aug 2020 at 20:50, Peter Williams <pet...@gm...> wrote: > Following my previous note on installing pdf in PlPlot using linux mint 20 > 64bit. > > I have used cmake on libharu-RELEASE_2_3_0 to produce a directory libharu > which contains the include and lib directories. > I then use cmake on plplot-5.10.0. to produce a directory plplot > containing directories bin, include, lib and share. > The pdf driver is not installed. During the latter cmake the following > cmake.out message is produced: > > -- Looking for haru pdf header and library > -- Looking for haru pdf header and library - not found > -- WARNING: Setting PLD_pdf to OFF. > > I have since amended plplot-5_3.0/cmake/module/Findhpdf.cmake in the > following (kludged) fragment: > ' > ' > find_path(hpdf_INCLUDE_DIR hpdf.h PATHS /usr/local/include /usr/include > PATH_SUFFIXES hpdf) > find_path(hpdf_INCLUDE_DIR hpdf.h PATHS /usr/local/include /usr/include) > find_path(hpdf_INCLUDE_DIR hpdf.h PATHS > /home/peter/software/libharu/include) > > if(hpdf_INCLUDE_DIR) > find_library(hpdf_LIBRARY > NAMES hpdf > PATHS /usr/local/lib /usr/lib /home/peter/software/libharu/lib > ) > ' > ' > The above cmake.out message is now: > > -- Looking for haru pdf header and library > -- Findhpdf: Found haru header directory, > /home/peter/software/libharu/include, and library, > /home/peter/software/libharu/lib/libhpdf.so. > -- Looking for haru pdf header and library - found > -- Checking whether libharu version >= 2.3.0 > -- Performing Test LIBHARU_VERSION_LARGE_ENOUGH > -- Performing Test LIBHARU_VERSION_LARGE_ENOUGH - Success > ' > ' > DRIVERS_LIST: mem;null;pdf;ps;svg;xfig;xwin > DEVICES_LIST: mem;null;pdf;ps;psc;svg;xfig;xwin > > I now test on a simple plpot program x03.c using > > gcc -c -I /home/peter/software/plplot/include/plplot x03.c > gcc -o x03.exe x03.o -L /home/peter/software/plplot/lib -L > /home/peter/software/libharu/lib -lplplot -lcsirocsa -lqsastime -lhpdfs > -lm -pthread -lX11 > > and to my dismay get > > peter@peter-Akoya-E6237:~/software/Test$ sh x03.sh > > /usr/bin/ld: /home/peter/software/libharu/lib/libhpdfs.a(hpdf_streams.o): > in function `HPDF_Stream_WriteToStreamWithDeflate': > hpdf_streams.c:(.text+0x118f): undefined reference to `deflateInit_' > /usr/bin/ld: hpdf_streams.c:(.text+0x127a): undefined reference to > `deflateEnd' > /usr/bin/ld: hpdf_streams.c:(.text+0x129a): undefined reference to > `deflate' > > Can't see these last three functions in libharu-RELEASE_2_3_0/src. > > Any advice? > > Best wishes, Peter. > > On Tue, 28 Jul 2020 at 15:51, Peter Williams <pet...@gm...> > wrote: > >> Hello Plplot >> I am new to linux (mint 20). I am experiencing some difficulty in adding >> the pdf driver to my plplot installation. >> I have been following the instructions from the README_cmake file. >> I have downloaded libharu-RELEASE_2_3_0.zip and unpacked its contents to >> libharu in /home/peter/ where I also created a libharau_build folder. I cd >> into this directory and ran cmake (version 3.16.3) as >> >> cmake -DBUILD_SHARED_LIBS=OFF ../libharu >> >> I then ran "make". The run concluded with >> "[100%] Linking C static library libhpdfs.a >> [100%] Built target hpdfs " (I have a log of the process) >> >> I now seem to have, in my build directory a include directory containing >> hpdf_config.h and a >> src directory containing libhpdf.so (a shared library? !) and (among >> other things) libhpdfs.a. This latter file presumably contains the static >> pdf library for use by cmake in rebuilding plplot. >> >> I then rebuilt plplot (using the default setting to include pdf) and the >> setting to generate static libraries: >> cmake -DCMAKE_INSTALL_PREFIX:PATH=/home/peter/plplot >> /home/peter/plplot_install/plplot-5.15.0 -DBUILD_SHARED_LIBS=OFF >& >> cmake.out >> I can see no evidence of pdf being enabled. In fact, cmake.out contains >> "Looking for haru pdf header and library >> -- Looking for haru pdf header and library - not found >> -- WARNING: Setting PLD_pdf to OFF." >> >> Can you please tell me where I should move libhpdfs.a (and hpdf_config.h >> ?) to rebuild plplot successfuly. >> >> Your advice would be gratefully received. >> Peter. >> >> -- >> Peter Williams >> pet...@gm... >> >> > > -- > Peter Williams > pet...@gm... > 27 Ramsbury Road, St. Albans, AL1 1SN, UK > -- Peter Williams pet...@gm... 27 Ramsbury Road, St. Albans, AL1 1SN, UK |
From: Peter W. <pet...@gm...> - 2020-08-04 19:51:20
|
Following my previous note on installing pdf in PlPlot using linux mint 20 64bit. I have used cmake on libharu-RELEASE_2_3_0 to produce a directory libharu which contains the include and lib directories. I then use cmake on plplot-5.10.0. to produce a directory plplot containing directories bin, include, lib and share. The pdf driver is not installed. During the latter cmake the following cmake.out message is produced: -- Looking for haru pdf header and library -- Looking for haru pdf header and library - not found -- WARNING: Setting PLD_pdf to OFF. I have since amended plplot-5_3.0/cmake/module/Findhpdf.cmake in the following (kludged) fragment: ' ' find_path(hpdf_INCLUDE_DIR hpdf.h PATHS /usr/local/include /usr/include PATH_SUFFIXES hpdf) find_path(hpdf_INCLUDE_DIR hpdf.h PATHS /usr/local/include /usr/include) find_path(hpdf_INCLUDE_DIR hpdf.h PATHS /home/peter/software/libharu/include) if(hpdf_INCLUDE_DIR) find_library(hpdf_LIBRARY NAMES hpdf PATHS /usr/local/lib /usr/lib /home/peter/software/libharu/lib ) ' ' The above cmake.out message is now: -- Looking for haru pdf header and library -- Findhpdf: Found haru header directory, /home/peter/software/libharu/include, and library, /home/peter/software/libharu/lib/libhpdf.so. -- Looking for haru pdf header and library - found -- Checking whether libharu version >= 2.3.0 -- Performing Test LIBHARU_VERSION_LARGE_ENOUGH -- Performing Test LIBHARU_VERSION_LARGE_ENOUGH - Success ' ' DRIVERS_LIST: mem;null;pdf;ps;svg;xfig;xwin DEVICES_LIST: mem;null;pdf;ps;psc;svg;xfig;xwin I now test on a simple plpot program x03.c using gcc -c -I /home/peter/software/plplot/include/plplot x03.c gcc -o x03.exe x03.o -L /home/peter/software/plplot/lib -L /home/peter/software/libharu/lib -lplplot -lcsirocsa -lqsastime -lhpdfs -lm -pthread -lX11 and to my dismay get peter@peter-Akoya-E6237:~/software/Test$ sh x03.sh /usr/bin/ld: /home/peter/software/libharu/lib/libhpdfs.a(hpdf_streams.o): in function `HPDF_Stream_WriteToStreamWithDeflate': hpdf_streams.c:(.text+0x118f): undefined reference to `deflateInit_' /usr/bin/ld: hpdf_streams.c:(.text+0x127a): undefined reference to `deflateEnd' /usr/bin/ld: hpdf_streams.c:(.text+0x129a): undefined reference to `deflate' Can't see these last three functions in libharu-RELEASE_2_3_0/src. Any advice? Best wishes, Peter. On Tue, 28 Jul 2020 at 15:51, Peter Williams <pet...@gm...> wrote: > Hello Plplot > I am new to linux (mint 20). I am experiencing some difficulty in adding > the pdf driver to my plplot installation. > I have been following the instructions from the README_cmake file. > I have downloaded libharu-RELEASE_2_3_0.zip and unpacked its contents to > libharu in /home/peter/ where I also created a libharau_build folder. I cd > into this directory and ran cmake (version 3.16.3) as > > cmake -DBUILD_SHARED_LIBS=OFF ../libharu > > I then ran "make". The run concluded with > "[100%] Linking C static library libhpdfs.a > [100%] Built target hpdfs " (I have a log of the process) > > I now seem to have, in my build directory a include directory containing > hpdf_config.h and a > src directory containing libhpdf.so (a shared library? !) and (among other > things) libhpdfs.a. This latter file presumably contains the static pdf > library for use by cmake in rebuilding plplot. > > I then rebuilt plplot (using the default setting to include pdf) and the > setting to generate static libraries: > cmake -DCMAKE_INSTALL_PREFIX:PATH=/home/peter/plplot > /home/peter/plplot_install/plplot-5.15.0 -DBUILD_SHARED_LIBS=OFF >& > cmake.out > I can see no evidence of pdf being enabled. In fact, cmake.out contains > "Looking for haru pdf header and library > -- Looking for haru pdf header and library - not found > -- WARNING: Setting PLD_pdf to OFF." > > Can you please tell me where I should move libhpdfs.a (and hpdf_config.h > ?) to rebuild plplot successfuly. > > Your advice would be gratefully received. > Peter. > > -- > Peter Williams > pet...@gm... > > -- Peter Williams pet...@gm... 27 Ramsbury Road, St. Albans, AL1 1SN, UK |
From: Peter W. <pet...@gm...> - 2020-07-28 14:51:33
|
Hello Plplot I am new to linux (mint 20). I am experiencing some difficulty in adding the pdf driver to my plplot installation. I have been following the instructions from the README_cmake file. I have downloaded libharu-RELEASE_2_3_0.zip and unpacked its contents to libharu in /home/peter/ where I also created a libharau_build folder. I cd into this directory and ran cmake (version 3.16.3) as cmake -DBUILD_SHARED_LIBS=OFF ../libharu I then ran "make". The run concluded with "[100%] Linking C static library libhpdfs.a [100%] Built target hpdfs " (I have a log of the process) I now seem to have, in my build directory a include directory containing hpdf_config.h and a src directory containing libhpdf.so (a shared library? !) and (among other things) libhpdfs.a. This latter file presumably contains the static pdf library for use by cmake in rebuilding plplot. I then rebuilt plplot (using the default setting to include pdf) and the setting to generate static libraries: cmake -DCMAKE_INSTALL_PREFIX:PATH=/home/peter/plplot /home/peter/plplot_install/plplot-5.15.0 -DBUILD_SHARED_LIBS=OFF >& cmake.out I can see no evidence of pdf being enabled. In fact, cmake.out contains "Looking for haru pdf header and library -- Looking for haru pdf header and library - not found -- WARNING: Setting PLD_pdf to OFF." Can you please tell me where I should move libhpdfs.a (and hpdf_config.h ?) to rebuild plplot successfuly. Your advice would be gratefully received. Peter. -- Peter Williams pet...@gm... |
From: Arjen M. <Arj...@de...> - 2020-07-23 12:23:17
|
Hi Peter, See below. Regards, Arjen From: Peter Williams <pet...@gm...> Sent: 22 July 2020 21:39 To: plp...@li... Subject: [Plplot-general] Linking in Linux Hello Plplot I am at present migrating some PlPlot programs from Windows 10 to linux (mint 64 bit), To facilitate this I have downloaded cmake and Plplot-5.15.0.tar.gz from your website. Following the instructions from your wiki I built an installation consisting of static libraries. In order to test the installation I wrote a very simple program PlPlotTest.c: #include <stdio.h> #include "plplot.h" int main() { printf("Plotting example\n"); plsdev("ps"); plsfnam("TestPlplot.ps");plinit(); plenv(-1.0 , 1.0 ,-1.0,1.0,1,2); pljoin(-0.5,-0.5,0.5,0.5); plend(); printf("Plot finished\n"); return 1; } and attempted to compile it with gcc -c -I /home/peter/plplot/install_directory/include/plplot PlPlotTest.c gcc -o PlPlotTest.exe PlPlotTest.o -L /home/peter/plplot/install_directory/lib -lplplot -lcsirocsa -lqsastime -lm -lX11 An object file PlPlotTest.o was generated with no errors, but the linking failed with the messages: /usr/bin/ld: /home/peter/plplot/install_directory/lib/libplplot.a(xwin.c.o): in function `plD_init_xw': xwin.c:(.text+0x470): undefined reference to `pthread_mutexattr_init' /usr/bin/ld: xwin.c:(.text+0x481): undefined reference to `pthread_mutexattr_settype' /usr/bin/ld: xwin.c:(.text+0x519): undefined reference to `pthread_create' /usr/bin/ld: /home/peter/plplot/install_directory/lib/libplplot.a(xwin.c.o): in function `plD_tidy_xw': xwin.c:(.text+0xcd0): undefined reference to `pthread_cancel' /usr/bin/ld: xwin.c:(.text+0xcec): undefined reference to `pthread_join' collect2: error: ld returned 1 exit status >>AM: These unresolved symbols are from the pthreads library. I am not sure why, but CMake has decided that you should use pthreads – the xwin.c source file contains a macro PL_USE_PTHREADS_XWIN. And when that is defined at compile time, from the configuration file, the relevant code is compiled in. The solution is therefore: add -lpthread as a link option (not -lpthreads 😊). 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. |
From: Peter W. <pet...@gm...> - 2020-07-23 11:55:26
|
Thank you Alan and Arjen -pthread works just fine in the link. I don't think it is needed in the compile stage as cmake must automatically entail it. Unless there is a way of configuring cmake to not do this? BTW on my first run of cmake, -DBUILD_SHARED_LIBS was absent so shared libraries were generated instead of static ones. Then, the compilation and linking of PlPlotTest.c went all the way without error. But the executable would not run and produced an error message about not being able to use the shared libraries - I'm afraid I don't have a copy of the exact message. I then re-ran cmake to produce static libraries. Best Wishes Peter On Thu, 23 Jul 2020 at 08:59, Alan W. Irwin <Ala...@gm...> wrote: > On 2020-07-22 20:38+0100 Peter Williams wrote: > > > Hello Plplot > > I am at present migrating some PlPlot programs from Windows 10 to linux > > (mint 64 bit), > > To facilitate this I have downloaded cmake and Plplot-5.15.0.tar.gz from > > your website. > > Following the instructions from your wiki I built an installation > > consisting of static > > libraries. In order to test the installation I wrote a very simple > program > > PlPlotTest.c: > > > > #include <stdio.h> > > #include "plplot.h" > > int main() > > { > > printf("Plotting example\n"); > > plsdev("ps"); plsfnam("TestPlplot.ps");plinit(); > > plenv(-1.0 , 1.0 ,-1.0,1.0,1,2); > > pljoin(-0.5,-0.5,0.5,0.5); > > plend(); > > printf("Plot finished\n"); > > return 1; > > } > > and attempted to compile it with > > > > gcc -c -I /home/peter/plplot/install_directory/include/plplot > PlPlotTest.c > > gcc -o PlPlotTest.exe PlPlotTest.o -L > > /home/peter/plplot/install_directory/lib -lplplot -lcsirocsa -lqsastime > > -lm -lX11 > > > > An object file PlPlotTest.o was generated with no errors, but the linking > > failed with [undefined pthread library references]. > > > I am very new to linux. Can you tell me what the linking should be? > > Hi Peter: > > If you execute "man gcc" and look for the -pthread option it says > > "-pthread > Define additional macros required for using the POSIX threads library. > You should use this option > consistently for both compilation and linking." > > Therefore, I suggest you add the -pthread option to *both* the compile > (gcc -c ....) and link (gcc -o ....) steps above to see if those > changes solve solve the pthread library linking issues you have > encountered. > > 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 > __________________________ > -- Peter Williams pet...@gm... 27 Ramsbury Road, St. Albans, AL1 1SN, UK |