Re: [pcre-dev] coff file info and data

Top Page
Delete this message
Author: Bob Rossi
Date:  
To: pcre-dev
Subject: Re: [pcre-dev] coff file info and data
On Sat, Apr 14, 2007 at 06:39:16AM -0400, Bob Rossi wrote:
> On Tue, Apr 03, 2007 at 09:37:49AM -0400, Sheri wrote:
> > Coff file which puts version and license resources info into the dll.
> > Currently hard coded to put "7.1 RC3" into the version string.
>
> Hi Sheri,
>
> I took a look at this. So, from what I understand, the old build system
> (pcre-7.0) simply made the dll named pcre.dll all the time. There was no
> version information embedded in the library. From what I can see, this
> is worse than what we have today with pcre-7.1.
>
> The coff and rc files that you are showing in the attachment were never
> distributed with pcre previously, correct? These are additions to the
> build system that you would like to see in the new version of pcre?
> (pcre-7.1)
>
> I have a few comments. It seems that the autotools build system of pcre
> should definately be using the libtool version numbers to create the
> pcre dll with the name pcre-0.dll. That's how the GNU tool chain seems
> to expect the filenames of a dll on mingw/cygwin. Here are two good
> articles that explain this,
>
> http://sourceware.org/autobook/autobook/autobook_91.html
> http://home.att.net/~perlspinr/build_platforms/cygwin/libversioning.html
>
> I can think of 3 solutions to this problem. Probably others should chime
> in here to decide what is best.
>
> - Not provide you with the functionality you are requesting
>
> - Allow either the CMake or a Visual C build system to be put on top of
> pcre that would provide this functionality naturally.
>
> - Add a configure option, say, --alternate-win32-dll-names or something,
> that would let the build system do everything it does now, and then
> run a few extra commands (the ones that you sent in basically).
>
> What does everyone think?


Here is some follow up information by Brain describing what the coff
file info is,

pcre.rc file:
VALUE "FileDescription", "Perl Compatible Regular Expressions"                                   
VALUE "LegalCopyright", "refer to license"                                                       
VALUE "FileVersion", "7.1 RC3"                                                                   
VALUE "License", "PCRE is a library of functions to support regular expressions whose syntax and sema                                                                                                   
VALUE "WWW", "http://www.pcre.org"                                                               


This is just a resource, same as putting an icon, cursor, string text,                                  
menu, etc in the binary.  RC = resource compiler, windres = windows                                     
resource tool.  The version is completely informative, it is not                                        
actually used by the system (exception below.)  You still only link                                     
against just "PCRE.DLL", there is no way to tell the system "I need                                     
PCRE.DLL version X".                                                                                    


The exception is the side-by-side assembly, a feature present only in XP                                
and later, where you include a manifest (an XML file either embedded as                                 
resource or as a standalone foo.exe.manifest file) which specifies the                                  
version of the libraries your app is linked against.  This is used by                                   
the system to allow twelve dozen (or whatever) versions of things like                                  
comctl32.dll, which in the past were particularly prone to DLL hell.  If                                
you look in %WINDIR%\WinSxS you will see all the various versioned                                      
libraries that the system has installed.  The system handles this                                       
transparently whenever some installer tries to put its own comctl32.dll                                 
in %WINDIR%\system32.                                                                                   


But this is something that (as far as I know) is handled by the system                                  
and only applies to system DLLs (i.e. things under %WINDIR%\system32)                                   
that are on some special list.  I don't think it applies to                                             
libraries/DLLs in the general sense; even if it did, you could not count                                
on it to solve your problems as it doesn't even exist on                                                
Win2k/NT/95/98/etc.  And there is zero support for it in libtool or any                                 
of the GNU toolchains, aside from the fact that you can manually create                                 
an XML manifest with a text editor and use windres to add it to the                                     
.exe.                                                                                                   


Brian