On 2010-11-11 09:04+0100 Arjen Markus wrote:
> Hi Alan,
>
> On 2010-11-10 21:42, Alan W. Irwin wrote:
>> On 2010-11-10 08:50+0100 Arjen Markus wrote:
>>> The crash (assertion failure) I mentioned with one particular setting
>>> of PLPLOT_DRV_DIR is caused solely by the appearance of files with
>>> extension ".rc" in the dll\Debug subdirectory when using Visual Studio.
>>> They are related to "manifest files" for the Fortran DLLs. Perhaps we
>>> should have a look at the reading procedure for the PLplot .rc files
>>> to avoid this crash, but it seems rare enough a condition not to put
>>> much emphasis on that.
>>
>> I am allergic to letting bugs slide (especially if they involve the
>> build system) so could you explain the issue further?
>>
>> On Linux the <top-level-build-tree>/drivers/<driver>.rc files are
>> configured by cmake (see the logic in
>> cmake/modules/drivers-finish.cmake). Those files describe which
>> devices have been enabled for each device driver. The test-drv-info
>> application generates exactly the same information from the driver
>> plugin that has been built, and there is a cmake custom target
>> (test_${SOURCE_ROOT_NAME}_dyndriver, see drivers/CMakeLists.txt) for
>> each driver that checks the two sets of information are identical as a
>> test that the driver plugin is OK. As far as I know, these
>> driver-related *.rc files all should occur in the drivers subdirectory
>> even on Windows. Do these files have anything to do with your
>> troubles above or is it something entirely unrelated?
>>
>> If the troubles are due to some weird Windows nameclash with the .rc
>> suffix on the driver-related *.rc files, the motivation for that
>> choice of suffix is lost in the mists of time, and we could certainly
>> change that suffix to something else that is much more distinctive
>> (such as .driver_info).
>>
>
> The Visual Studio build produces .rc files (where rc is an abbreviation
> of resource compiler, IIUIC) that are subsequently used by the resource
> compiler to produce .res files (resource files), which are most probably
> incorporated in the DLLs. Here is the content of one of these
> intermediate files:
>
> 2 /* ISOLATIONAWARE_MANIFEST_RESOURCE_ID */ 24 /* RT_MANIFEST */
> "D:\\plplot-svn\\build-windows-vs2008-2\\dll\\Debug\\plplotf95d.dll.embed.manifest"
>
> I will not claim to understand what is going on here, I only
> superficially understand the use of manifest files.
>
> If we are going to use an extension "driver_info" instead of "rc" it is
> very unlikely we run into such trouble again.
OK. I have changed (revision 11323) the ".rc" suffix for the driver
information files to ".driver_info" to avoid this possible name clash
(and to use a more descriptive suffix). I tested that fairly major
change pretty thoroughly, but no issues showed up.
>
> But perhaps we ought to be prepared for ill-formatted driver files. I
> just examined the code and I see that we expect the file to have a
> number of tokens separated by colons - and there is no check on whether
> these tokens actually exist! So, a quick patch would be to check that
> we have these tokens. That would eliminate the problem I reported
> without us having to introduce a different extension.
>
> I will work on this.
I saw your subsequent commit. It's a good idea to install a core
library check like you did for bad driver information in (the
unlikely) case the external checks (referred to above) somehow fail to
detect such bad information. Of course, this is an entirely separate
issue from the nameclash one solved above.
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
__________________________
------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
