Menu
▾
▴
#39 Otherwise working PLPlot examples dont work on Win7/64
Have PLPlot working under WinXP64, all PLPlot examples tested work. Have "distributed" those exe's to WinXP32, and so long as a suitable collection of "drivers" etc are included, those all work directly on XP32 (i.e. there is not a compilation, just a use of the exe's created on XP64)
However, attempting to distribute/run any of the standard example exe's on Win7/64 fails.
In addition to attempting to "distribute" the exe's (as with the XP32 tests), have also now built the full compiler/MSys2/PLPlot/CodeBlock mechanism on Win7/64. Everything compiles correctly, but attempting to run the code (directly from the IDE), produces exactly the same results as attempting to run a pre-built/distributed exe. For example, with hl_cairo1.exe w/extcairo:
pl_create_tempfile: Unable to open temporary file - returning
plInitDispatchTable: Could not open temporary file, aborting operation
and then it has the usual request for alternate driver, all of which fails.
Initially, the Win7 setup was identical to that of XP64 and XP32 withrespect to paths/env's, and distributed drivers. That failed.
Now. have copied EVERY file (drivers, dll's, info's, maps, etc etc) to every possibly related dir. Have put all those Dir's on the paths, and set all the Env vars as per the PLPlot manual ... but still get these errors on Win7 ... while the same things (with less grief over paths, etc) work on XP64, and XP32.
It is difficult to see how the required files are not "seen" by PLPlot, as they are on so many paths/locations that with certainty PLPlot sees the Dir contents (e.g. some of the PLPlot examples require GTK dll's, which it does see. Yet, all the PLPLot files are also in the same dir where the GTK dll's reside, but which PLPlot fails to see/use in a workable manner).
Is it possible that this is not a "path" issue at all, but perhaps some "Win7 permission thing" or other machinations in the bowls of Win7.
In any case, any assistance would be greatly appreciated.
I have performed additinoal tests in Win7, by giving all the obvious Dir's "Full permission", and even adding "Everyone" with full permissions ... makes no difference, same warnings/errors.
Perhaps some information about which sr/, and why, is actually throwing the pl_create_tempfile, and plInitDispatchTable errors would be helpful.
Also, it may be helpful if when PLPlot cannot find drivers etc it is looking for, that it might actually print additional information, such as, where it thinks those files should be.
Please advise.
The function pl_create_tempfile() is defined in src/plstdio.c (line 172). It looks like it is trying to create a temp file in the "c:\windows\temp" directory.
Maybe it works for you because you are an administrator, but it doesn't work for other because they are not?
-Hazen
Cheers for that, but I think we may be talking about two different things.
Under Win7/64, PLPlot does NOT work under ANY circumstances to the extent that it throws the errors stated above. We are always logged in as Admin, we always run the exe As Admin.
Also, in addition to "distributing" the exe's to Win7, we have also installed then ENTIRE production systems with CodeBlocks(CB)/MSys2/GNU5.3.0, and built from scratch the entire PLPlot 5.11.1 lib (built from scratch under Win7/64), and set all paths/env's etc. We can compile and create the exe's in Win7/64, but on trying to run the app from CB they FAIL in exactly the same way as the stand alone exe's.
We have also changed the permissions on every single dir we could think of, to give FULL permissions to all Dir's, and have also added the EveryOne "user" with full permissions to all of those Dir's.
We looked at the code you had kindly pointed to, and we tried a number of things. For example, we considered the possibility that under Win7/64, the macro WIN32 may not be defined (e.g. line 182 or 196), in which case it looks to a temp dir with a different name (TMPDIR). So we created an extra ENV for that and pointed to the standard TEMP dir, just in case ... no joy ... same errors.
So, thus far, It does not matter what we do, it will not get past the errors above under Win7/64 ... in spite of the fact that the exact same things work in WinXP32, WinXP64 (both as stand alone, and also from the IDE), and on WinXP32 we only test as "stand alone" (i.e. no IDE/compiler, just the exe's, and the minimum required PLPlot lib's for the distribution)
... just out of curiousity, has anyone used PLPlot successfully under Win7/64? If so, we would be interested to know what they have done.
Hi DrO,
I have had quite a lot of success with plplot on my sub-systems on a multi-boot computer (win7/64, XP32 (but hardly ever invoked) , linux). It is a stand-alone single-user system and so possibly simpler than yours to run. I use msys2 but haven't updated since February so I can't speak to its recent state. I don;t use any IDE's, just the msys shell. The folks on the msys2-users mailing list are responsive and usually helpful. It is a "rolling release" but unlike debian linux, there is no army of users running tests, and no "legacy stable" versions to fall back to.
You didn't mention how many bindings you want to build into plplot. By default plplot will "try them all" if it finds configurable files. I run using "MSYS Makefiles" almost exclusively, although "UNIX makefiles" will work almost just as well. "MINGW Makefiles" applies to using a different set of tools (not the posix MSYS tools) and I haven't had success doing it this way (it is robust, but not as easy as msys).
From your posts it is hard for me to identify any recognizable problem except a general haywired-ness. My initial thought is that you edit /etc/profile to exclude all third-party paths (even windows may not be necessary) and re-build the PATH export to have just /mingw/bin:<msys> to work with ...</msys>
Here are excerpts from my own /etc/profile which is run for msys2. It incorporates a mingw.org distribution also:
Cmake will look at the environment it wakes up in, especially now in the path. Generally running Cmake from an msys shell with the path simplified as I advised will work, there are a few examples where the actual location of the cmake.exe can make a difference. Running it from /mingw/bin (without a symlink trick) is advisable. Certainly, though, inspect the output ( >& cmake.out) for unwanted influences.
You probably do want to cling to the mingw.org distribution for XP32 usage but this can also be driven with the msys2 system. If you are using a mingw-w64 compiler be aware that you are not connecting to mingw.org version except by way of its msys shell. There are a few installation recipes out there that have you installing a mingw-w64 distribution on top of mingw/msys. This overrides the original mingw but it doesn't remove it, so problems might arise from that. I don't know what the XP support policy is for the -w64 folks.
Running your result:
I use the override environment variables for the data required by plplot:
The drivers get put into the <prefix>/lib/plplot5.11.1/drivers directory, these need to be copied to
one of the $PATH directories.</prefix>
After that there's no particular env variable that you need, but probably a few possible
names from other dstributions that might interfere - so inspect the output of "env" for suspects,
and cancel them out in the /etc/profile if you are still running haywire after a clean install.
Greg
SUSSED IT!
It seems the problem has nothing to do with manner in which PLPlot is installed (e.g. from scratch, MSys2, etc). The problem here, somewhat like "issue 38" turns out to be a COLLISION between PLPlot and Intel Fortran (XE).
Previously we had discovered that if there is another Fortran compiler on the Path (in addition go GNU/gFortran/MingW etc), then the MAKE/build will get "messed" up and not all the libs/etc are built, since it may try to use IVF (or whatever) instead of gFortran, and that breaks many things. We found that to be a problem already on any other version of Windows. The solution we instutionalised was to MAKE PPlot with the Windows CMD shell, and set a specific path that for that session.
The current problem in Win7/64 is also an artefact of Intel's "machinations", perahps coupled with some things the PLPlot machinary could do a little better.
The short answer, and "easy" solution is: the problem was with how the TEMP ENV is used by BOTH PLPlot AND other apps, and can lead to "collisions". Amongst other things:
1) PLPlot should put some printf() statements into plstdio.c around line 217, so when it does crash, at least there is a chance to know why it is complaining. We did this, and rebuilt PLPlot, and immediately became clear why it was crashing and pointed us to solutions.
2) PLPlot uses the getenv() approach to obtain the path for TEMP. However, this is getting TEMP from the USER ENV's (c.f. the System ENV's). As such, it opens the way for collisions, even if the collisions are ultimately caused by others (e.g. Intel). There are number of possible solutions for this, some of which are:
a) Use the WINAPI GetEnvironmentVariable() instead, which permits distinguishing between User and System ENV's, and then any USER ENV collisions are immediately obviated.
b) PLPlot's "use" of TEMP performs no "validity checking", it simply "tacks on" the PLPlot temp file name to the what ever is at the end of the(User) TEMP path, which can (and in our case did) produce nonsense ... some little checking/care by the code here would have obviated this problem.
c) In our case, since the Intel inftrastructure is rather messy and delicate, we did not wish to mess with that (i.e. the change the current User ENV TEMP), since that ment loosing all of that machinary.
Our SOLUTION:
Instead, we altered the getenv() line in plstdio.c to look for a new ENV we called PLPlot_TEMP, which we created as a new User ENV, and set a simple temp path for it. Then, rebuild PLPlot, re-booted Win to make sure the the ENV's were "set" ... and Bob's your uncle ... it works
... Hazen deserves some of the credit for pointing us to the file/line where the original PLPlot problem initiates ...
... Many thanks to everyone ...
I have substantially improved pl_create_tempfile by rewriting it. See commit 62b5e5290 from the PLplot git master branch. That commit message details all the various extensive tests I did of this new code on Linux. In addition I am fairly confident this new code will solve the present issue as well on Windows since the code also tries a series of directories to find one that works as opposed to just looking at the first possibility in the list that is non-NULL. The list now includes TMP (in case that is different from TEMP) and the current directory so I am pretty sure it should work fine for your case, but I request you test the git master branch to confirm that. By the way, you should now be able to use the -debug command line option to discover which directories are tried. See the commit message for examples of using the -debug option.
Dear Alan:
Sorry about the lateness of my reply.
I have not been able to test the fixes due to some new and very important matters that are completely consuming my time.
However, I will say that I had omitted some details from previous submissions as they would have diluted the story and required a lengthy digression, and which may or may not impact all that many users. Amongst other things, on the Win7/64 installation where these issues were discovered, one of the strange aspects of the Intel software is that it seems to hijack the TEMP ENV settings in an idiosyncratic manner. For example, their install places a ";" at the end of the paths listed in TEMP. If that ";" is removed, the Intel software fails to work correctly. This means that simply adding the PLPlot temp file name to the last member of the TEMP path(s) creates a "broken" link.
For example, the Intel install has a long list of paths in TEMP, say with the last one being "C:\Something;" If now, only a file name is appended (and which is expecting the last TEMP path to end without a ";", then one ends up with TEMP ending as "C:\Something;\PLPlotxxxx.yyy". Clearly, that will always fail.
Put differently, attempting to "piggy back" a PLPlot file onto an existing TEMP dir fails due to the "Intel strangeness".
Although we have moved off of Intel products to the greatest extent possible, it is still required for certain/occasional legacy issues, otherwise it would most certainly not be on our machines. Thus, our solution was to re-write PLPlot's plstdio.c file and have it create a pristine PLPlot_Temp ENV with its own path, on that machine.
Cheers
DrO
PS. You may have noticed that I had not responded to you last comment wrt to issue #38. I did see your note, but I could not follow the link to the new location to which you had moved the discussion. In any case, and as noted earlier in #38, we consider the matter "solved", noting that users should be aware that using make/cmake in Win CMD shell can confuse itself if there are multiple Fortran compilers installed (e.g. if PLPlot sees Intel or whatever Fortran before it sees gFortran, and the user is intending a MinGW-style make, then it will fail (presumably this would be true of any case with multiple compilers). The simple solution is to be sure that the CMD shell used for make/cmake etc has its own PATH set, including only the desired compiler(s).
Since others have now tested our solution to this issue on Windows I am going to close this support request. Feel free to open it again if you run into any more problems with PLplot's use of temporary files.