From: Arjen M. <arj...@de...> - 2009-03-27 09:20:22
|
Hi, the new set-up to get the driver .rc files seems to be failing under Cygwin. I have no idea why: I am not overly familiar with libtool and its inner workings, but what happens is this: The test-drv-info runs to completion but writes an empty string to the screen - and hence the .rc file is empty. Can anyone confirm this or better indicate a solution? Regards, Arjen Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 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: Werner S. <sm...@ia...> - 2009-03-27 09:35:59
|
Hi Arjen, does cygwin find the dlls, i.e. is the dll directory with the dynamic drivers in the PATH? It's still Windows ;). Regards, Werner On 27.03.2009, at 10:20, Arjen Markus wrote: > Hi, > > the new set-up to get the driver .rc files seems to be > failing under Cygwin. I have no idea why: I am not overly > familiar with libtool and its inner workings, but what > happens is this: > > The test-drv-info runs to completion but writes an > empty string to the screen - and hence the .rc file > is empty. > > Can anyone confirm this or better indicate a solution? > > Regards, > > Arjen > > > Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of > TNO and parts of Rijkswaterstaat have joined forces in a new > independent institute for delta technology, Deltares. Deltares > combines knowledge and experience in the field of water, soil and > the subsurface. We provide innovative solutions to make living in > deltas, coastal areas and river basins safe, clean and sustainable. > > > > DISCLAIMER: This message is intended exclusively for the > addressee(s) and may contain confidential and privileged > information. If you are not the intended recipient please notify the > sender immediately and destroy this message. Unauthorized use, > disclosure or copying of this message is strictly prohibited. > The foundation 'Stichting Deltares', which has its seat at Delft, > The Netherlands, Commercial Registration Number 41146461, is not > liable in any way whatsoever for consequences and/or damages > resulting from the improper, incomplete and untimely dispatch, > receipt and/or content of this e-mail. > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Arjen M. <arj...@de...> - 2009-03-27 10:07:57
|
Hi Werner, well, the DLLs are in the same directory, and the test-drv-info program explicitly loads them. So, I would expect that failure to find results in an error message (induced by a NULL pointer) rather a silent stop. Regards, Arjen On 2009-03-27 10:35, Werner Smekal wrote: > Hi Arjen, > > does cygwin find the dlls, i.e. is the dll directory with the dynamic > drivers in the PATH? It's still Windows ;). > > Regards, > Werner > > On 27.03.2009, at 10:20, Arjen Markus wrote: > >> Hi, >> >> the new set-up to get the driver .rc files seems to be >> failing under Cygwin. I have no idea why: I am not overly >> familiar with libtool and its inner workings, but what >> happens is this: >> >> The test-drv-info runs to completion but writes an >> empty string to the screen - and hence the .rc file >> is empty. >> >> Can anyone confirm this or better indicate a solution? >> >> Regards, >> >> Arjen >> >> >> Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO >> and parts of Rijkswaterstaat have joined forces in a new independent >> institute for delta technology, Deltares. Deltares combines knowledge >> and experience in the field of water, soil and the subsurface. We >> provide innovative solutions to make living in deltas, coastal areas >> and river basins safe, clean and sustainable. >> >> >> >> DISCLAIMER: This message is intended exclusively for the addressee(s) >> and may contain confidential and privileged information. If you are >> not the intended recipient please notify the sender immediately and >> destroy this message. Unauthorized use, disclosure or copying of this >> message is strictly prohibited. >> The foundation 'Stichting Deltares', which has its seat at Delft, The >> Netherlands, Commercial Registration Number 41146461, is not liable in >> any way whatsoever for consequences and/or damages resulting from the >> improper, incomplete and untimely dispatch, receipt and/or content of >> this e-mail. >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Plplot-devel mailing list >> Plp...@li... >> https://lists.sourceforge.net/lists/listinfo/plplot-devel > > -- > Dr. Werner Smekal > Institut fuer Allgemeine Physik > Technische Universitaet Wien > Wiedner Hauptstr 8-10 > A-1040 Wien > Austria > > email: sm...@ia... > web: http://www.iap.tuwien.ac.at/~smekal > phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) > fax: +43-(0)1-58801-13499 > > Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 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: Alan W. I. <ir...@be...> - 2009-03-27 16:17:12
|
On 2009-03-27 10:20+0100 Arjen Markus wrote: > Hi, > > the new set-up to get the driver .rc files seems to be > failing under Cygwin. I have no idea why: I am not overly > familiar with libtool and its inner workings, but what > happens is this: > > The test-drv-info runs to completion but writes an > empty string to the screen - and hence the .rc file > is empty. Hi Arjen, Please give more details to help the rest of us understand the issue you have run into on Cygwin. There are two .rc files per device driver. One configured by cmake in drivers, and the one created by test-drv-info in drivers/test_dyndrivers_dir. You imply the first one is fine and the second one is empty, but could you confirm that? If the second one is empty, it means that dynamic loading doesn't even pass an elementary test on Cygwin and certainly no dynamically loaded device driver would work when you try to run PLplot. Please run test-drv-info by hand (don't forget "make VERBOSE=1" to figure out how you do that) and report back the exact command and every message (if any) that is given by that elementary test of dynamic loading. Beyond that, there are two possibilities to use on Cygwin for dynamic loading. Either Werner's windows solution or the Cygwin package http://cygwin.com/packages/libltdl3/. Just to clarify what is going on can you state which is being using? Currently, I don't think you have a choice. Instead, our build system will pick one of them. But which one? Use ldd on test-drv-info to find out. If our build system chooses libltdl, do you have the latest/greatest version installed properly? 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 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: Arjen M. <arj...@de...> - 2009-03-30 09:20:44
|
Hello Alan, Werner, On 2009-03-27 17:16, Alan W. Irwin wrote: > On 2009-03-27 10:20+0100 Arjen Markus wrote: > >> Hi, >> >> the new set-up to get the driver .rc files seems to be >> failing under Cygwin. I have no idea why: I am not overly >> familiar with libtool and its inner workings, but what >> happens is this: >> >> The test-drv-info runs to completion but writes an >> empty string to the screen - and hence the .rc file >> is empty. > > Hi Arjen, > > Please give more details to help the rest of us understand the issue you > have run into on Cygwin. > > There are two .rc files per device driver. One configured by cmake in > drivers, and the one created by test-drv-info in > drivers/test_dyndrivers_dir. You imply the first one is fine and the > second > one is empty, but could you confirm that? If the second one is empty, it > means that dynamic loading doesn't even pass an elementary test on Cygwin > and certainly no dynamically loaded device driver would work when you try > to run PLplot. I ran test-drv-info manually, there was no output to the screen. (I saw that from the empty .rc file appearing in the "test-drivers" (if I remember the name correctly) subdirectory as well). > > Please run test-drv-info by hand (don't forget "make VERBOSE=1" to figure > out how you do that) and report back the exact command and every message > (if > any) that is given by that elementary test of dynamic loading. > I am not sure you can state it that generally: a build I did early february (and still had around) does work with dynamic drivers! Only then we used the get-drv-info program to create the .rc files. > Beyond that, there are two possibilities to use on Cygwin for dynamic > loading. Either Werner's windows solution or the Cygwin package > http://cygwin.com/packages/libltdl3/. Just to clarify what is going on can > you state which is being using? Currently, I don't think you have a > choice. > Instead, our build system will pick one of them. But which one? Use > ldd on test-drv-info to find out. I have not had an opportunity to do that yet. > > If our build system chooses libltdl, do you have the latest/greatest > version > installed properly? > Quite probably it is an old one, but as I said before: it has worked in a previous build. So my suspicion is that the relatively new test-drv-info program does something different. I will try and find out what that difference is. Regards, Arjen Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 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: Alan W. I. <ir...@be...> - 2009-03-30 17:45:27
|
On 2009-03-30 11:20+0200 Arjen Markus wrote: > I ran test-drv-info manually, there was no output to the screen. > (I saw that from the empty .rc file appearing in the "test-drivers" (if > I remember the name correctly) subdirectory as well). > >> >> Please run test-drv-info by hand (don't forget "make VERBOSE=1" to figure >> out how you do that) and report back the exact command and every message >> (if >> any) that is given by that elementary test of dynamic loading. Hi Arjen: It's a long shot, but there was some purpose to my question. So please answer it with the _exact_ command (test-drv-info + argument), that was run by make VERBOSE=1 including the directory the command was run in. test-drv-info is simply a renamed version of get-drv-info with no actual code changes. So it bothers me that there is absolutely no error message from it. (There have always been such error messages in the past if something was wrong with the dynamic loading or with the argument that was used.) What happens if you use a different/wrong argument to it? Do you get an error message then, and if so what? I made some minor CMake changes to the way the code is built and run so probably the best bet is there is something wrong there for the Cygwin case (but not for the actual C-code itself). >> >> If our build system chooses libltdl, do you have the latest/greatest >> version >> installed properly? >> > > Quite probably it is an old one, but as I said before: it has worked in > a previous build. So my suspicion is that the relatively new > test-drv-info program does something different. I will try and find > out what that difference is. I have just double-checked by downloading get-drv-info.c (revision 9475) from our repository and it is identical to test-drv-info.c. So the issue is not due to a code change between get-drv-info.c and test-drv-info.c. 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 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: Werner S. <sm...@ia...> - 2009-03-30 20:10:32
|
Hi Alan and Arjen, > Hi Arjen: > > It's a long shot, but there was some purpose to my question. So please > answer it with the _exact_ command (test-drv-info + argument), that was run > by make VERBOSE=1 including the directory the command was run in. > > test-drv-info is simply a renamed version of get-drv-info with no actual > code changes. So it bothers me that there is absolutely no error message > from it. (There have always been such error messages in the past if > something was wrong with the dynamic loading or with the argument that was > used.) What happens if you use a different/wrong argument to it? Do you get > an error message then, and if so what? > > I made some minor CMake changes to the way the code is built and run so > probably the best bet is there is something wrong there for the Cygwin case > (but not for the actual C-code itself). > > >>> If our build system chooses libltdl, do you have the latest/greatest >>> version >>> installed properly? >>> >>> >> Quite probably it is an old one, but as I said before: it has worked in >> a previous build. So my suspicion is that the relatively new >> test-drv-info program does something different. I will try and find >> out what that difference is. >> > > I have just double-checked by downloading get-drv-info.c (revision 9475) > from our repository and it is identical to test-drv-info.c. So the issue is > not due to a code change between get-drv-info.c and test-drv-info.c. > > Alan > I know what the problem is, but a solution is not straight forward. Arjen, the problem, why test-drv-info doesn't produce any results is, that it can't find a dll which is linked into test-drv-info. If you use Dependency Walker (http://www.dependencywalker.com/) you'll find out, that test-drv-info needs libplplotd-9.6.1.dll cygwin1.dll cygltdl-7.dll kernel32.dll The first one is in src and can't therefore be found, since for cygwin we don't let cmake move all dlls into the dll directory (even if you put the dll path in the PATH environment variable). test-drv-info is linked to PLplot library due to the call to plGetDrvDir(). The plplot dll depends itself on qsastime, csa and nn library. So if you export the following to the PATH environment variable: export PATH=...build/lib/csa:$PATH export PATH=...build/lib/nn:$PATH export PATH=...build/lib/qsastime:$PATH export PATH=...build/src:$PATH test-drv-info.exe works then. The dll path workaround for the other Win32 compilers doesn't work here, since in test-drv-info.c we have: snprintf( drvspec, DRVSPEC_LEN, "%s/%s", plGetDrvDir (), drvnam ); So there is always the output of plGetDrvDir() prepended to the driver name, which would in this case (all dlls are in the dll directory) not be necessary. So only for cygwin this would need to be changed. And presumably where the driver dlls are actually opened as well. I already did some changes and will commit later, so that cygwin works similar to the other Win32 compiler toolsets (all dlls are in dll directory, and plplot just opens the dll without path). Regards, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria DVR-Nr: 0005886 email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2009-03-30 21:01:30
|
On 2009-03-30 22:10+0200 Werner Smekal wrote: > I know what the problem is, but a solution is not straight forward. > [..]I already did some changes and will commit later, so that cygwin works > similar to the other Win32 compiler toolsets (all dlls are in dll directory, > and plplot just opens the dll without path). Thanks, Werner, for digging into this issue and finding what sounds like a good solution. What I find disconcerting about Arjen's error report is the lack of error message (other than no output) when test-drv-info could not find the PLplot library. If I arrange that case on Linux by temporarily renaming the PLplot library, test-drv-info generates the following useful error message: software@raven> ./test-drv-info ps ./test-drv-info: error while loading shared libraries: libplplotd.so.9: cannot open shared object file: No such file or directory Are we stuck with the bad result that ./test-drv-info silently dies (no error message other than no output file) for the corresponding Cygwin case or is it possible you could fix that? 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 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: Werner S. <sm...@ia...> - 2009-03-31 06:26:53
|
Hi Alan, > > What I find disconcerting about Arjen's error report is the lack of > error > message (other than no output) when test-drv-info could not find the > PLplot > library. If I arrange that case on Linux by temporarily renaming > the PLplot > library, test-drv-info generates the following useful error message: > > software@raven> ./test-drv-info ps > ./test-drv-info: error while loading shared libraries: libplplotd.so. > 9: > cannot open shared object file: No such file or directory > > Are we stuck with the bad result that ./test-drv-info silently dies > (no > error message other than no output file) for the corresponding > Cygwin case > or is it possible you could fix that? I remember that we had this problem already in the past, so this is a known problem (even for us :). I searched the internet thoroughly and eventually found something: http://sourceware.org/ml/cygwin/2009-01/msg00312.html http://sourceware.org/ml/cygwin/2009-01/msg00320.html According to the mailing list entries, this is a bug in cygwin, which is fixed in the next version (1.7), which is now in beta at the moment. If you run the test-drv-info executable not in cygwin, but in the normal Windows CLI a message pops up, which tells one that the dll is not found. So, we are stuck with this bad result and could do nothing about it (since the program exits before the main routine is entered) and have to wait for the next cygwin version. Regards, Werner > > 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 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 -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Arjen M. <arj...@de...> - 2009-03-31 06:38:20
|
Hi Werner, I think it is not just a problem with Cygwin: quite frequently the only error message from a program that can not run for lack of a DLL is that it immediately returns. I am not sure under what circumstances this happens, but I think the following scenario provides them: Program A depends on DLL B DLL B can be found in the path, but it depends on DLL C. DLL C can NOT be found Result: Program A can not run, but does not give a message, simply terminates. Regards, Arjen On 2009-03-31 08:26, Werner Smekal wrote: > Hi Alan, > >> What I find disconcerting about Arjen's error report is the lack of >> error >> message (other than no output) when test-drv-info could not find the >> PLplot >> library. If I arrange that case on Linux by temporarily renaming >> the PLplot >> library, test-drv-info generates the following useful error message: >> >> software@raven> ./test-drv-info ps >> ./test-drv-info: error while loading shared libraries: libplplotd.so. >> 9: >> cannot open shared object file: No such file or directory >> >> Are we stuck with the bad result that ./test-drv-info silently dies >> (no >> error message other than no output file) for the corresponding >> Cygwin case >> or is it possible you could fix that? > > I remember that we had this problem already in the past, so this is a > known problem (even for us :). I searched the internet thoroughly and > eventually found something: > > http://sourceware.org/ml/cygwin/2009-01/msg00312.html > http://sourceware.org/ml/cygwin/2009-01/msg00320.html > > According to the mailing list entries, this is a bug in cygwin, which > is fixed in the next version (1.7), which is now in beta at the > moment. If you run the test-drv-info executable not in cygwin, but in > the normal Windows CLI a message pops up, which tells one that the dll > is not found. > > So, we are stuck with this bad result and could do nothing about it > (since the program exits before the main routine is entered) and have > to wait for the next cygwin version. > > Regards, > Werner > >> 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 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 > > -- > Dr. Werner Smekal > Institut fuer Allgemeine Physik > Technische Universitaet Wien > Wiedner Hauptstr 8-10 > A-1040 Wien > Austria > > email: sm...@ia... > web: http://www.iap.tuwien.ac.at/~smekal > phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) > fax: +43-(0)1-58801-13499 > > > ------------------------------------------------------------------------------ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 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...> - 2009-03-31 06:30:34
|
Hi Alan, On 2009-03-30 19:44, Alan W. Irwin wrote: > > It's a long shot, but there was some purpose to my question. So please > answer it with the _exact_ command (test-drv-info + argument), that was run > by make VERBOSE=1 including the directory the command was run in. > > test-drv-info is simply a renamed version of get-drv-info with no actual > code changes. So it bothers me that there is absolutely no error message > from it. (There have always been such error messages in the past if > something was wrong with the dynamic loading or with the argument that was > used.) What happens if you use a different/wrong argument to it? Do you > get > an error message then, and if so what? > Well, I solved the problem: it turns out that Werner was on the right track - I needed to expand the PATH environment variable, not with the drivers subdirectory that contains the DLLs, but with the src subdirectory, as apparently "test-drv-info" links to "libplplot-9.6.1.dll"! I realised that something like this was going wrong by manually running it with various arguments and extra print-statements. (By the way: it is using libtool as supplied by Cygwin. Interestingly when I forced it to use Werner's utilities, it did run! So, in that case it does not seem to depend on libplplot-9.6.1.dll ...) > I made some minor CMake changes to the way the code is built and run so > probably the best bet is there is something wrong there for the Cygwin case > (but not for the actual C-code itself). > >>> >>> If our build system chooses libltdl, do you have the latest/greatest >>> version >>> installed properly? >>> >> >> Quite probably it is an old one, but as I said before: it has worked in >> a previous build. So my suspicion is that the relatively new >> test-drv-info program does something different. I will try and find >> out what that difference is. > > I have just double-checked by downloading get-drv-info.c (revision 9475) > from our repository and it is identical to test-drv-info.c. So the > issue is > not due to a code change between get-drv-info.c and test-drv-info.c. > No, it is indeed the PATH that requires attention. That brings me to the following question: is it possible to expand the PATH variable automatically during the build process? I can of course expand it before I start "make", but then we burden every user with that. Putting that into the Makefiles seems much more elegant. Or at the very least: that is what I think now. Regards, Arjen Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 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: Werner S. <sm...@ia...> - 2009-03-31 07:05:02
|
Hi Arjen, > Well, I solved the problem: it turns out that Werner was on the right > track - I needed to expand the PATH environment variable, not with > the drivers subdirectory that contains the DLLs, but with the src > subdirectory, as apparently "test-drv-info" links to > "libplplot-9.6.1.dll"! > > I realised that something like this was going wrong by manually > running > it with various arguments and extra print-statements. Interesting, I did the same, but there was nothing printed on the screen ever until I added all missing dlls to the PATH? > > (By the way: it is using libtool as supplied by Cygwin. Interestingly > when I forced it to use Werner's utilities, it did run! So, in that > case it does not seem to depend on libplplot-9.6.1.dll ...) The reason is, that I don't use PLplot function which provides the path to the driver directory. Cygwin runs on Windows after all and dlls must be in the same directory, in the PATH or in the system directories. So we have the choice now to use my implementation for libltdl or libtool, but then we must change the code for cygwin accordingly what I already did for my implementation. So it may be better to use my implementation after all. > >> I made some minor CMake changes to the way the code is built and >> run so >> probably the best bet is there is something wrong there for the >> Cygwin case >> (but not for the actual C-code itself). >> >>>> >>>> If our build system chooses libltdl, do you have the latest/ >>>> greatest >>>> version >>>> installed properly? >>>> >>> >>> Quite probably it is an old one, but as I said before: it has >>> worked in >>> a previous build. So my suspicion is that the relatively new >>> test-drv-info program does something different. I will try and find >>> out what that difference is. >> >> I have just double-checked by downloading get-drv-info.c (revision >> 9475) >> from our repository and it is identical to test-drv-info.c. So the >> issue is >> not due to a code change between get-drv-info.c and test-drv-info.c. >> > > No, it is indeed the PATH that requires attention. > > That brings me to the following question: is it possible to expand the > PATH variable automatically during the build process? I can of course > expand it before I start "make", but then we burden every user with > that. Putting that into the Makefiles seems much more elegant. Or at > the very least: that is what I think now. Yesterday, I had exactly the same idea as you. Just recently there was a discussion on the CMake mailing list about exactly this problem. I'll reread it and change the CBS accordingly. So that the dll directory is included to the path, so that test-drv-info is able to run without problems as well as the examples if you are using - DBUILD_TEST=ON. At least in the build tree anything works without any user interaction. But these changes to the PATH variable will not be permanently, so if you run the examples or test-drv-info by hand they won't work. Arjen, btw, in cygwin I have the same problem with the fortran 77 compiler (no import library created for libplplotf77d-9.1.1.dll) when I add -DBUILD_TEST=ON. Can you confirm that? Regards, Werner > > Regards, > > Arjen > > > Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of > TNO and parts of Rijkswaterstaat have joined forces in a new > independent institute for delta technology, Deltares. Deltares > combines knowledge and experience in the field of water, soil and > the subsurface. We provide innovative solutions to make living in > deltas, coastal areas and river basins safe, clean and sustainable. > > > > DISCLAIMER: This message is intended exclusively for the > addressee(s) and may contain confidential and privileged > information. If you are not the intended recipient please notify the > sender immediately and destroy this message. Unauthorized use, > disclosure or copying of this message is strictly prohibited. > The foundation 'Stichting Deltares', which has its seat at Delft, > The Netherlands, Commercial Registration Number 41146461, is not > liable in any way whatsoever for consequences and/or damages > resulting from the improper, incomplete and untimely dispatch, > receipt and/or content of this e-mail. > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Arjen M. <arj...@de...> - 2009-03-31 07:34:02
|
Hi Werner, On 2009-03-31 09:04, Werner Smekal wrote: > Hi Arjen, > >> >> I realised that something like this was going wrong by manually running >> it with various arguments and extra print-statements. > > Interesting, I did the same, but there was nothing printed on the screen > ever until I added all missing dlls to the PATH? Well, I did not have any output either: that is when I realised the program was not starting at all! >> >> (By the way: it is using libtool as supplied by Cygwin. Interestingly >> when I forced it to use Werner's utilities, it did run! So, in that >> case it does not seem to depend on libplplot-9.6.1.dll ...) > > The reason is, that I don't use PLplot function which provides the path > to the driver directory. Cygwin runs on Windows after all and dlls must > be in the same directory, in the PATH or in the system directories. So > we have the choice now to use my implementation for libltdl or libtool, > but then we must change the code for cygwin accordingly what I already > did for my implementation. So it may be better to use my implementation > after all. Do you have that working? Because I tried that myself and that led to a program that did start but refused to accept the driver DLL. >> >> No, it is indeed the PATH that requires attention. >> >> That brings me to the following question: is it possible to expand the >> PATH variable automatically during the build process? I can of course >> expand it before I start "make", but then we burden every user with >> that. Putting that into the Makefiles seems much more elegant. Or at >> the very least: that is what I think now. > > Yesterday, I had exactly the same idea as you. Just recently there was a > discussion on the CMake mailing list about exactly this problem. I'll > reread it and change the CBS accordingly. So that the dll directory is > included to the path, so that test-drv-info is able to run without > problems as well as the examples if you are using -DBUILD_TEST=ON. At > least in the build tree anything works without any user interaction. But > these changes to the PATH variable will not be permanently, so if you > run the examples or test-drv-info by hand they won't work. > I realise that, but it seems better than having to restart the build process half way, because I forgot ;). Or I think it is better ... > Arjen, btw, in cygwin I have the same problem with the fortran 77 > compiler (no import library created for libplplotf77d-9.1.1.dll) when I > add -DBUILD_TEST=ON. Can you confirm that? > Yes, I can. That is the next issue that needs to be solved. No idea yet why this is not happening. Regards, Arjen Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 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...> - 2009-04-03 07:03:16
|
Hi Werner, > > Arjen, btw, in cygwin I have the same problem with the fortran 77 > compiler (no import library created for libplplotf77d-9.1.1.dll) when I > add -DBUILD_TEST=ON. Can you confirm that? > I have solved the problem (not committed yet): I introduced a file Cygwin-GNU-Fortran.cmake with almost the same contents as Windows-GNU-Fortran.cmake (but without the conditions) and that does the trick. I will commit it asap. That does leave a few questions, like: how does the build work for g95? What about static libraries and pkg-config (one vexing question from some time back)? But I can tackle them one by one. Regards, Arjen Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 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...> - 2009-04-01 07:54:25
|
Hi Werner, I think I found the cause: it was a bit hidden in directories I normally don't look at: I had a special CMake module for gfortran in cmake/Modules/Platform. I never committed it, apparently, but now I have. Could you check if that makes dlltool superfluously for you? If so, we can simplify the build script. I also checked if the compiler options I used for gfortran under MinGW would do the job for Cygwin too and that is the case. So, my next move will be to expand that module for gfortran under Cygwin as well. (That would leave g95, I guess, as another popular compiler - should be very much the same). Regards, Arjen On 2009-03-31 09:04, Werner Smekal wrote: > Hi Arjen, > >> Well, I solved the problem: it turns out that Werner was on the right >> track - I needed to expand the PATH environment variable, not with >> the drivers subdirectory that contains the DLLs, but with the src >> subdirectory, as apparently "test-drv-info" links to >> "libplplot-9.6.1.dll"! >> >> I realised that something like this was going wrong by manually running >> it with various arguments and extra print-statements. > > Interesting, I did the same, but there was nothing printed on the screen > ever until I added all missing dlls to the PATH? >> >> (By the way: it is using libtool as supplied by Cygwin. Interestingly >> when I forced it to use Werner's utilities, it did run! So, in that >> case it does not seem to depend on libplplot-9.6.1.dll ...) > > The reason is, that I don't use PLplot function which provides the path > to the driver directory. Cygwin runs on Windows after all and dlls must > be in the same directory, in the PATH or in the system directories. So > we have the choice now to use my implementation for libltdl or libtool, > but then we must change the code for cygwin accordingly what I already > did for my implementation. So it may be better to use my implementation > after all. >> >>> I made some minor CMake changes to the way the code is built and run so >>> probably the best bet is there is something wrong there for the >>> Cygwin case >>> (but not for the actual C-code itself). >>> >>>>> >>>>> If our build system chooses libltdl, do you have the latest/greatest >>>>> version >>>>> installed properly? >>>>> >>>> >>>> Quite probably it is an old one, but as I said before: it has worked in >>>> a previous build. So my suspicion is that the relatively new >>>> test-drv-info program does something different. I will try and find >>>> out what that difference is. >>> >>> I have just double-checked by downloading get-drv-info.c (revision 9475) >>> from our repository and it is identical to test-drv-info.c. So the >>> issue is >>> not due to a code change between get-drv-info.c and test-drv-info.c. >>> >> >> No, it is indeed the PATH that requires attention. >> >> That brings me to the following question: is it possible to expand the >> PATH variable automatically during the build process? I can of course >> expand it before I start "make", but then we burden every user with >> that. Putting that into the Makefiles seems much more elegant. Or at >> the very least: that is what I think now. > > Yesterday, I had exactly the same idea as you. Just recently there was a > discussion on the CMake mailing list about exactly this problem. I'll > reread it and change the CBS accordingly. So that the dll directory is > included to the path, so that test-drv-info is able to run without > problems as well as the examples if you are using -DBUILD_TEST=ON. At > least in the build tree anything works without any user interaction. But > these changes to the PATH variable will not be permanently, so if you > run the examples or test-drv-info by hand they won't work. > > Arjen, btw, in cygwin I have the same problem with the fortran 77 > compiler (no import library created for libplplotf77d-9.1.1.dll) when I > add -DBUILD_TEST=ON. Can you confirm that? > > Regards, > Werner > >> >> Regards, >> >> Arjen >> >> >> Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO >> and parts of Rijkswaterstaat have joined forces in a new independent >> institute for delta technology, Deltares. Deltares combines knowledge >> and experience in the field of water, soil and the subsurface. We >> provide innovative solutions to make living in deltas, coastal areas >> and river basins safe, clean and sustainable. >> >> >> >> DISCLAIMER: This message is intended exclusively for the addressee(s) >> and may contain confidential and privileged information. If you are >> not the intended recipient please notify the sender immediately and >> destroy this message. Unauthorized use, disclosure or copying of this >> message is strictly prohibited. >> The foundation 'Stichting Deltares', which has its seat at Delft, The >> Netherlands, Commercial Registration Number 41146461, is not liable in >> any way whatsoever for consequences and/or damages resulting from the >> improper, incomplete and untimely dispatch, receipt and/or content of >> this e-mail. >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Plplot-devel mailing list >> Plp...@li... >> https://lists.sourceforge.net/lists/listinfo/plplot-devel > > -- > Dr. Werner Smekal > Institut fuer Allgemeine Physik > Technische Universitaet Wien > Wiedner Hauptstr 8-10 > A-1040 Wien > Austria > > email: sm...@ia... > web: http://www.iap.tuwien.ac.at/~smekal > phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) > fax: +43-(0)1-58801-13499 > > Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 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: Werner S. <sm...@ia...> - 2009-04-15 06:32:23
|
Hi Arjen, > > I think I found the cause: it was a bit hidden in directories I > normally > don't look at: I had a special CMake module for gfortran in > cmake/Modules/Platform. I never committed it, apparently, but now I > have. That explains a lot ;) > > Could you check if that makes dlltool superfluously for you? If so, > we can simplify the build script. I didn't test it with MinGW 4/GFortran yet, but with Cygwin f77 and MinGW f77 - and both work now! So the files Cygwin-GNU-Fortran.cmake and Windows-GNU-Fortran.cmake also influence the f77 linker options. I tested only shared libraries so we still need to test for static, but that's great news. I'll revert my dlltool changes and commit them. Thanks, Werner > > I also checked if the compiler options I used for gfortran under MinGW > would do the job for Cygwin too and that is the case. So, my next move > will be to expand that module for gfortran under Cygwin as well. > (That would leave g95, I guess, as another popular compiler - should > be very much the same). > > Regards, > > Arjen > > On 2009-03-31 09:04, Werner Smekal wrote: >> Hi Arjen, >> >>> Well, I solved the problem: it turns out that Werner was on the >>> right >>> track - I needed to expand the PATH environment variable, not with >>> the drivers subdirectory that contains the DLLs, but with the src >>> subdirectory, as apparently "test-drv-info" links to >>> "libplplot-9.6.1.dll"! >>> >>> I realised that something like this was going wrong by manually >>> running >>> it with various arguments and extra print-statements. >> >> Interesting, I did the same, but there was nothing printed on the >> screen >> ever until I added all missing dlls to the PATH? >>> >>> (By the way: it is using libtool as supplied by Cygwin. >>> Interestingly >>> when I forced it to use Werner's utilities, it did run! So, in that >>> case it does not seem to depend on libplplot-9.6.1.dll ...) >> >> The reason is, that I don't use PLplot function which provides the >> path >> to the driver directory. Cygwin runs on Windows after all and dlls >> must >> be in the same directory, in the PATH or in the system directories. >> So >> we have the choice now to use my implementation for libltdl or >> libtool, >> but then we must change the code for cygwin accordingly what I >> already >> did for my implementation. So it may be better to use my >> implementation >> after all. >>> >>>> I made some minor CMake changes to the way the code is built and >>>> run so >>>> probably the best bet is there is something wrong there for the >>>> Cygwin case >>>> (but not for the actual C-code itself). >>>> >>>>>> >>>>>> If our build system chooses libltdl, do you have the latest/ >>>>>> greatest >>>>>> version >>>>>> installed properly? >>>>>> >>>>> >>>>> Quite probably it is an old one, but as I said before: it has >>>>> worked in >>>>> a previous build. So my suspicion is that the relatively new >>>>> test-drv-info program does something different. I will try and >>>>> find >>>>> out what that difference is. >>>> >>>> I have just double-checked by downloading get-drv-info.c >>>> (revision 9475) >>>> from our repository and it is identical to test-drv-info.c. So the >>>> issue is >>>> not due to a code change between get-drv-info.c and test-drv- >>>> info.c. >>>> >>> >>> No, it is indeed the PATH that requires attention. >>> >>> That brings me to the following question: is it possible to expand >>> the >>> PATH variable automatically during the build process? I can of >>> course >>> expand it before I start "make", but then we burden every user with >>> that. Putting that into the Makefiles seems much more elegant. Or at >>> the very least: that is what I think now. >> >> Yesterday, I had exactly the same idea as you. Just recently there >> was a >> discussion on the CMake mailing list about exactly this problem. I'll >> reread it and change the CBS accordingly. So that the dll directory >> is >> included to the path, so that test-drv-info is able to run without >> problems as well as the examples if you are using -DBUILD_TEST=ON. At >> least in the build tree anything works without any user >> interaction. But >> these changes to the PATH variable will not be permanently, so if you >> run the examples or test-drv-info by hand they won't work. >> >> Arjen, btw, in cygwin I have the same problem with the fortran 77 >> compiler (no import library created for libplplotf77d-9.1.1.dll) >> when I >> add -DBUILD_TEST=ON. Can you confirm that? >> >> Regards, >> Werner >> >>> >>> Regards, >>> >>> Arjen >>> >>> >>> Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of >>> TNO >>> and parts of Rijkswaterstaat have joined forces in a new independent >>> institute for delta technology, Deltares. Deltares combines >>> knowledge >>> and experience in the field of water, soil and the subsurface. We >>> provide innovative solutions to make living in deltas, coastal areas >>> and river basins safe, clean and sustainable. >>> >>> >>> >>> DISCLAIMER: This message is intended exclusively for the >>> addressee(s) >>> and may contain confidential and privileged information. If you are >>> not the intended recipient please notify the sender immediately and >>> destroy this message. Unauthorized use, disclosure or copying of >>> this >>> message is strictly prohibited. >>> The foundation 'Stichting Deltares', which has its seat at Delft, >>> The >>> Netherlands, Commercial Registration Number 41146461, is not >>> liable in >>> any way whatsoever for consequences and/or damages resulting from >>> the >>> improper, incomplete and untimely dispatch, receipt and/or content >>> of >>> this e-mail. >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Plplot-devel mailing list >>> Plp...@li... >>> https://lists.sourceforge.net/lists/listinfo/plplot-devel >> >> -- >> Dr. Werner Smekal >> Institut fuer Allgemeine Physik >> Technische Universitaet Wien >> Wiedner Hauptstr 8-10 >> A-1040 Wien >> Austria >> >> email: sm...@ia... >> web: http://www.iap.tuwien.ac.at/~smekal >> phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 >> (laboratory) >> fax: +43-(0)1-58801-13499 >> >> > > > Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of > TNO and parts of Rijkswaterstaat have joined forces in a new > independent institute for delta technology, Deltares. Deltares > combines knowledge and experience in the field of water, soil and > the subsurface. We provide innovative solutions to make living in > deltas, coastal areas and river basins safe, clean and sustainable. > > > > DISCLAIMER: This message is intended exclusively for the > addressee(s) and may contain confidential and privileged > information. If you are not the intended recipient please notify the > sender immediately and destroy this message. Unauthorized use, > disclosure or copying of this message is strictly prohibited. > The foundation 'Stichting Deltares', which has its seat at Delft, > The Netherlands, Commercial Registration Number 41146461, is not > liable in any way whatsoever for consequences and/or damages > resulting from the improper, incomplete and untimely dispatch, > receipt and/or content of this e-mail. > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |