From: Alan W. I. <ir...@be...> - 2006-04-24 17:55:54
|
I just checked, and our MinGW fixes got into libtool-1.5.22. Because Hazen is using that latest libtool version to generate the tarball it means the MinGW patch no longer needs to be applied to cf/ltmain.sh, and I have updated INSTALL appropriately. So it appears that our MinGW/MSYS platform is now on an equal footing with our Cygwin platform. Both have almost fully matured now. The only issue I am aware of is that --enable-dyndrivers has not been tested so we don't know whether it works or not on those platforms. I am hopeful it will, however, since libtool tends to make big strides in such areas, and we are now using the latest version of libtool. Anyhow, I encourage those with access to MinGW or Cygwin to please give a thorough testing to Hazen's recently created test plplot-5.6.0.tar.gz tarball (at http://homepage.mac.com/hbabcock/) on those platforms. Use the default shared library (remember to have the "file" command installed!) and default --enable-dyndrivers ./configure options. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <aro...@ya...> - 2006-04-25 04:58:32
|
At 10:54 AM 24/04/2006 -0700, you wrote: >I just checked, and our MinGW fixes got into libtool-1.5.22. Because Hazen >is using that latest libtool version to generate the tarball it means the >MinGW patch no longer needs to be applied to cf/ltmain.sh, and I have >updated INSTALL appropriately. > >So it appears that our MinGW/MSYS platform is now on an equal footing with >our Cygwin platform. Both have almost fully matured now. The only issue I >am aware of is that --enable-dyndrivers has not been tested so we don't know >whether it works or not on those platforms. I am hopeful it will, however, >since libtool tends to make big strides in such areas, and we are now using >the latest version of libtool. --enable-dyndrivers still does not work with MinGW. -Andrew |
From: Alan W. I. <ir...@be...> - 2006-04-25 06:55:06
|
On 2006-04-25 14:54+1000 Andrew Roach wrote: > At 10:54 AM 24/04/2006 -0700, you wrote: >> I just checked, and our MinGW fixes got into libtool-1.5.22. Because >> Hazen >> is using that latest libtool version to generate the tarball it means the >> MinGW patch no longer needs to be applied to cf/ltmain.sh, and I have >> updated INSTALL appropriately. >> >> So it appears that our MinGW/MSYS platform is now on an equal footing with >> our Cygwin platform. Both have almost fully matured now. The only issue I >> am aware of is that --enable-dyndrivers has not been tested so we don't >> know >> whether it works or not on those platforms. I am hopeful it will, however, >> since libtool tends to make big strides in such areas, and we are now >> using >> the latest version of libtool. > > --enable-dyndrivers still does not work with MinGW. Too bad, but thanks for that test. Could you give some symptoms? Sometimes individual drivers fail with the get-drv-info test during the drivers build because of platform linking issues, but if you disable those drivers the rest (in particular the classic psc and ps devices which don't depend on any special external libraries) succeed indicating some linking issues (such as missing or inaccessible shared libraries) need to be resolved. Also, can you confirm that the patch of cf/ltmain.sh is no longer required, that is, the new libtool solves all the issues we had before with the old libtool for the shared libraries --disable-dyndrivers case? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <aro...@ya...> - 2006-04-25 12:39:22
|
>>--enable-dyndrivers still does not work with MinGW. > >Too bad, but thanks for that test. Could you give some symptoms? It fails the build process for the libraries with reported symbolic errors going back to the C++ bindings, though I think that is a symptom, not the problem. >Also, can you confirm that the patch of cf/ltmain.sh is no longer required, >that is, the new libtool solves all the issues we had before with the old >libtool for the shared libraries --disable-dyndrivers case? I have that version of libtool installed, but didn't have to patch plplot like I used to, so it looks fixed. -Andrew |
From: Arjen M. <arj...@wl...> - 2006-04-25 06:58:30
|
Andrew Roach wrote: > At 10:54 AM 24/04/2006 -0700, you wrote: > >> I just checked, and our MinGW fixes got into libtool-1.5.22. Because >> Hazen >> is using that latest libtool version to generate the tarball it means >> the >> MinGW patch no longer needs to be applied to cf/ltmain.sh, and I have >> updated INSTALL appropriately. >> >> So it appears that our MinGW/MSYS platform is now on an equal footing >> with >> our Cygwin platform. Both have almost fully matured now. The only >> issue I >> am aware of is that --enable-dyndrivers has not been tested so we >> don't know >> whether it works or not on those platforms. I am hopeful it will, >> however, >> since libtool tends to make big strides in such areas, and we are now >> using >> the latest version of libtool. > > > --enable-dyndrivers still does not work with MinGW. I should have time to try out the tarball on Cygwin and Windows with the MSVC compiler tonight. But I doubt if my conclusion will be different from Andrew's - having read about libtool, Cygwin, Windows, DLLs ... I think that the information I wrote about the Fortran 95 interface is fairly complete, even though there is no nice makefile or configure support for it yet. (I will not manage that ... I have just started to delve into the autotools world - fascinating and bewildering). I have written additional material for GD, UNICODE and antialiasing fonts with the win3 driver, but I have not committed it yet. As for the homebrewn configuration for that driver: it is well on its way - its job is far simpler than the overall configure script, as it only needs to find a few libraries and massage the makefile a bit, but still, as I want it to work smoothly, some work is still to be done. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2006-04-26 06:59:30
|
Alan W. Irwin wrote: > > Anyhow, I encourage those with access to MinGW or Cygwin to please give a > thorough testing to Hazen's recently created test plplot-5.6.0.tar.gz > tarball (at http://homepage.mac.com/hbabcock/) on those platforms. > Use the > default shared library (remember to have the "file" command > installed!) and > default --enable-dyndrivers ./configure options. Here are my test results for Cygwin and Windows/MSVC: Windows/MSVC: 1. Building the PLplot library and examples via the "configure.bat" script, using the default options works like a charm. The one exception is example x19 - it fails on pl_griddata(), which appears to be missing. I will have to look at that. 2. The examples work as expected. 3. I have not tested the GD and freetype libraries yet from the tarball - though I am making progress with the configuration stuff. Cygwin/wingcc: 0. I got some messages about the Python version I have installed - something about needing a development version? Given the other reports on the subject of Python builds, and my lack of knowledge on Python versions/installations, I have not looked into it further. 1. I tried with the dyndrivers option on: - The library and all examples are built without problems - The examples do NOT work correctly though! With wingcc I get a window that disappears immediately after the plot has been created, with others I got a lot of messages about the colour map being abused. The tests gave a lot of coredumps. 2. I rebuilt the library and examples without this option. It all worked (note: the shared library works for all languages I got support for - at least C, C++ and F77) 3. I turned off Tcl support - this gave errors late in the building process. 4. The tests were all fine with the static drivers. 5. Some comments on wingcc however: - While the plot appears, clicking in the window did not have any effect. - Closing the window did not end the program - I actually had to kill it via the Task manager or by killing the Cygwin console for it to stop. (I remember it that it just dumped core, when stopping, but I see this behaviour with the "old" version too - I suspect something otherwise unrelated to Cygwin has changed on my machine that causes this). Oh well, a lenghty report, but the conclusion is: - Cygwin still does not work with dyndrivers - We need to look into the wingcc driver a bit - Some work is yet to be done for the win3 driver Neither of these appear to be showstoppers - at least if others have no particular problems with the wingcc driver. Regards, Arjen |
From: Andrew R. <aro...@ya...> - 2006-04-26 20:11:23
|
At 08:58 AM 26/04/2006 +0200, you wrote: Cygwin/wingcc: >0. I got some messages about the Python version I have installed - > something about needing a development version? Given the > other reports on the subject of Python builds, and my lack of > knowledge on Python versions/installations, I have not looked > into it further. I get that error on MinGW too, but I don't even have python installed ! >1. I tried with the dyndrivers option on: > - The library and all examples are built without problems > - The examples do NOT work correctly though! > With wingcc I get a window that disappears immediately > after the plot has been created, with others I got a lot of > messages about the colour map being abused. > The tests gave a lot of coredumps. That is closer than MingW is getting - it wont even build the library. >5. Some comments on wingcc however: > - While the plot appears, clicking in the window did not > have any effect. Try the right mouse button instead of the left one. I am not sure which one the driver traps off the top of my head, but I think I was reserving the left mouse button for zooming and/or other operations. -Andrew |
From: Alan W. I. <ir...@be...> - 2006-04-26 22:04:39
|
On 2006-04-27 01:42+1000 Andrew Roach wrote: > At 08:58 AM 26/04/2006 +0200, you wrote: > Cygwin/wingcc: >> 0. I got some messages about the Python version I have installed - >> something about needing a development version? Given the >> other reports on the subject of Python builds, and my lack of >> knowledge on Python versions/installations, I have not looked >> into it further. > > I get that error on MinGW too, but I don't even have python installed ! That's the whole point. The default configuration is --enable-python. Thus, it looks for a valid python and if you don't have it, it warns you. To stop that warning either (a) --disable-python (which testers should not do if they want a complete test of the tarball on their platform) or (b) install the python and Numeric packages. Arjen, if you would like to complete your Cygwin tests for python, you should install the combination of http://cygwin.com/packages/python/python-2.4.1-1 and http://cygwin.com/packages/Numeric/Numeric-24.2-1. Andrew, if you would like to complete your MinGW tests for python, I think you must use a native windows python (which I assume is available from python.org) or else build your own following http://jove.prohosting.com/iwave/ipython/pyMinGW.html. For Numeric, a native windows build is available from http://sourceforge.net/project/showfiles.php?group_id=1369 or you can build your own. I know pre-release testing is time consuming, but python is an important platform for us so I would appreciate anything you both could do following the above suggestions for getting access to python/Numeric for your platforms. If our python interface still doesn't work after you have installed Python/Numeric, then please send _all_ the details.... configure.out, make.out, make_install.out, make_examples.out, plplot-test.out (or however far you get in the configure, build, install, build installed examples, and run examples sequence). I will take the time to read through those *.out results, and try and find a solution before release. Also, thanks to both of you for trying --disable-dyndrivers. Sorry it hasn't worked out on Cygwin and MinGW. My working hypothesis at the moment from what you two have reported is that the general PLplot-related dyn-drivers build is working fine on Cygwin, but there is something specifically wrong with the libtool libltdlc library for the Cygwin platform so the dynamic load does not work correctly, and a specific bug report to the libtool group about that might solve the matter. In contrast, the MinGW problem is more severe, and there is some general problem (perhaps similar to the previous sed issue) keeping Andrew from even building the PLplot-related part of the dyn-drivers build. From my point of view, these dynamic driver issues are not as high a priority as the python question (since --disable-dyndrivers works for all devices except the psttf and wxwidgets devices that are disabled in that case) so given pre-release time constraints we should let it slide for now. However, if either of you would like to sort this out post-release (like we previously did together for shared libraries), then I will try to find the time to help you out. But I don't have that time now. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <aro...@ya...> - 2006-04-27 02:58:52
|
>>I get that error on MinGW too, but I don't even have python installed ! > >That's the whole point. The default configuration is --enable-python. Thus, >it looks for a valid python and if you don't have it, it warns you. Ahhh... >Also, thanks to both of you for trying --disable-dyndrivers. Sorry it >hasn't worked out on Cygwin and MinGW. My working hypothesis at the moment >from what you two have reported is that the general PLplot-related >dyn-drivers build is working fine on Cygwin, but there is something >specifically wrong with the libtool libltdlc library for the Cygwin platform >so the dynamic load does not work correctly, and a specific bug report to >the libtool group about that might solve the matter. In contrast, the MinGW >problem is more severe, and there is some general problem (perhaps similar >to the previous sed issue) keeping Andrew from even building the >PLplot-related part of the dyn-drivers build. It could still be the same problem, but with MingW just catching it a little earlier than Cygwin. With MingW there are always warning messages which scroll past when you do a compile about "not allowing linking to dynamic libraries because windows doesn't allow undefined symbols, so it will substitute real symbols instead" or words to that effect. Because Cygwin has a number of extra compatibility layers in the form of add-on libraries for things like POSIX support, the resolution of those undefined symbols might not be happening until run time (then failing) whereas with MingW it might be getting caught during linking. -Andrew |
From: Arjen M. <arj...@wl...> - 2006-04-27 06:51:17
|
Alan W. Irwin wrote: > >> >> I get that error on MinGW too, but I don't even have python installed ! > > > That's the whole point. The default configuration is --enable-python. > Thus, > it looks for a valid python and if you don't have it, it warns you. > To stop > that warning either (a) --disable-python (which testers should not do if > they want a complete test of the tarball on their platform) or (b) > install > the python and Numeric packages. > > Arjen, if you would like to complete your Cygwin tests for python, you > should install the combination of > http://cygwin.com/packages/python/python-2.4.1-1 and > http://cygwin.com/packages/Numeric/Numeric-24.2-1. > Okay, I will look into the Python issue. We will need to add these packages to the INSTALL notes, I guess. As for the dynamic drivers: it is something of a run-time issue, the plots _are_ created, so it is not that the drivers are not found or not loaded, something odd is happening. But I agree: it is for later. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2006-04-27 04:14:53
|
On 2006-04-27 12:58+1000 Andrew Roach wrote: > [Alan said:] >> [...] In contrast, the >> MinGW >> problem is more severe, and there is some general problem (perhaps similar >> to the previous sed issue) keeping Andrew from even building the >> PLplot-related part of the dyn-drivers build. > > It could still be the same problem, but with MingW just catching it a little > earlier than Cygwin. With MingW there are always warning messages which > scroll past when you do a compile about "not allowing linking to dynamic > libraries because windows doesn't allow undefined symbols, so it will > substitute real symbols instead" or words to that effect. Because Cygwin has > a number of extra compatibility layers in the form of add-on libraries for > things like POSIX support, the resolution of those undefined symbols might > not be happening until run time (then failing) whereas with MingW it might be > getting caught during linking. I believe the --no-undefined option (used for all our library and device-driver plug-in builds as far as I know) is supposed to deal with the specific issue you mentioned, but in general you could be correct; it could be the same problem on both systems manifesting itself in various ways rather than some extra MinGW problem such as the one I speculated about above. Anyhow, we'll know a lot more post-release when there should be some time to look at all the details of what is going wrong. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2006-04-27 06:40:46
|
Andrew Roach wrote: > At 08:58 AM 26/04/2006 +0200, you wrote: > Cygwin/wingcc: > >> 0. I got some messages about the Python version I have installed - >> something about needing a development version? Given the >> other reports on the subject of Python builds, and my lack of >> knowledge on Python versions/installations, I have not looked >> into it further. > > > I get that error on MinGW too, but I don't even have python installed ! > Oh, that is more serious than I thought then - still not a showstopper, but I guess people may get very confused about it! > >> 1. I tried with the dyndrivers option on: >> - The library and all examples are built without problems >> - The examples do NOT work correctly though! >> With wingcc I get a window that disappears immediately >> after the plot has been created, with others I got a lot of >> messages about the colour map being abused. >> The tests gave a lot of coredumps. > > > That is closer than MingW is getting - it wont even build the library. ;) - but still, I am not sure that it is a good sign. (Gosh, my reply seems to turn out rather negative - that is not what I want) > > >> 5. Some comments on wingcc however: >> - While the plot appears, clicking in the window did not >> have any effect. > > > Try the right mouse button instead of the left one. I am not sure > which one the driver traps off the top of my head, but I think I was > reserving the left mouse button for zooming and/or other operations. > I am quite sure I tried that. I will check again. Regards, Arjen |