Alan, Arjen, This reminded me that I had a similar problem with strange things happening under Windows after the return call from test-drv-info.c. There is a long thread on the subject in May 2011 entitled Installing Plplot with Qt under Windows. In the end I think it came down to having absolutely everything - including DLLS - built with the same version of the same toolset with the same options.
Richard -----Original Message----- From: Arjen Markus [mailto:arjen.mar...@deltares.nl] Sent: 04 March 2013 12:21 To: Alan W. Irwin; PLplot development list Subject: Re: [Plplot-devel] Help needed with non-zero return code delivered by drivers/test-drv-info.c for certain devices on Windows platforms Hi Alan, see my answers inbetween Regards, Arjen On Thu, 28 Feb 2013 21:46:45 -0800 (PST) "Alan W. Irwin" <ir...@beluga.phys.uvic.ca> wrote: > Hi Arjen: > > I am directing this mostly to you because of your Windows expertise. > > I have been trying to build the wxwidgets device using MinGW/MSYS on >the Wine version of Windows. All goes well (which I will discuss in >a further post) except for one issue: > > bash.exe-3.1$ ../dll/test-drv-info.exe wxwidgets > > delivers the expected string > > wxwidgets:wxWidgets Driver:1:wxwidgets:51:wxwidgets > > but if you execute > > bash.exe-3.1$ echo $? > > right after the above command you find there is a return code of 3. > That non-zero return code generates a make error which can be worked >around by simply running make again (which is how I got the wxwidgets >windows results which I will post in the next message). > > Running test-drv-info.exe for ps, svg, or wingcc also generates the >expected strings in each case, but for these cases test-drv-info.exe >generates the correct return code of 0. > > I prefer we solve the test-drv-info.exe issue for wxwidgets for >MinGW/MSYS rather than forcing our users to work around it by building >twice so I looked at the test-drv-info.c code, and it generates the >above string by > > info = (char **) lt_dlsym( dlhand, sym ); > if ( info != NULL ) > { > printf( "%s", *info ); > return 0; > } > > So the question is how can test-drv-info.exe generate a non-zero >return code when it obviously executes the above printf statement and >therefore must obviously execute the above return 0; which is >equivalent to exit(0); in this main routine case? > > Wherever that return code is coming from, it appears not to be from >the code in test-drv-info.c since the exit and return commands all >return 0 or 1 which is obviously different from the return code of 3 >that I observe for wxwidgets. I therefore suspect the issue is >something done incorrectly by src/ltdl_win32.c in the lt_dlexit >routine for the case where dynamic loading loads additional libraries. >For example, our wxwidgets device depends on and therefore loads >wxWidgets libraries while our ps and svg devices have no external >library dependencies. (I am not quite sure of the status of the >wingcc device external library dependencies.) I have never seen this effect before. It may be some kind of leftover return code from cleaning up when the program exits (program code that belongs to the runtime library, not the user's code). While that is not very helpful, can you try with exit(0) instead of "return 0"? I can only make wild guesses where this is coming from, but it might even be that errno is being set to 3 during the execution of test-drv-info and that this value is then picked by the postamble code. Which might be an alternative ... (I know C programs tend to be rather sloppy in handling errno and also with the exit code, as they are usually harmless.) > > Two further questions: > > 1. Have you experienced this sort of issue before with certain of the >PLplot devices? I am pretty sure I remember reports from you before >about having to build twice to get around test-drv-info.exe issues, >but I cannot remember the specifics. > My experiences were with not having extended the PATH variable to include the dll subdirectory. That tends to give null-sized device info files. Since then extending that variable has become second nature :). > 2. Would you be willing to review and update src/ltdl_win32.c to >ensure it is doing everything correctly to handle dynamic loading for >the Windows case? > I can at the very least study it to see if this could be the cause. Quite frankly, I do not think it is, since there is no "return 3" anywhere there. I have also checked for atexit() calls - none that can be relevant. Regards, Arjen 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. ---------------------------------------------------------------------------- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
