Bob Rossi wrote:
> 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.
>>
Hi Bob,
Previously you said you wanted to change the file naming scheme so that
with every update there would be a different series of major and minor
numbers appended to the file names. I said I thought that would be
awful, because it would be impossible to update a pcre shared library
without altering the apps that use it. In the past it wouldn't have
mattered what file names got produced by configure/make; we could have
renamed them. But starting with 7.1 we must use two libraries (where
previously there was one) and now if the files are renamed, the posix
library can't find the pcre library.
Now (I think) you are saying that the files would likely be consistently
named libpcre-0.dll and libpcreposix-0.dll unless something happens to
break downward compatibility with dependent apps. That might generally
be a good thing. But now libpcreposix-0.dll is itself a dependent app.
So it will also need to be recreated if there is a change in the name of
libpcre-#.dll. In that respect I think the new 7.1 build is worse. Until
recently we used only the POSIX api and I believe our app was compatible
with every version of pcre since version 3 or so, and there was only one
dll file of concern. By updating only the (single) library and renaming
it to match what was used by our app, users managed to get the benefit
of certain improvements for regex matching (e.g., crlf newlines--if dll
default, named subpatterns for backreferences, etc.) . That's a lot of
version numbers that might have required developer intervention if the
(new) scheme had been in effect back then. Maybe there aren't too many
(Windows) users like us, I don't know. Also, presumedly in the future
our app will be more vulnerable to breaking since we are now adding
functionality from the native api. Suppose a Windows user has multiple
pcre library versions on their path (supporting muliple apps at
different version levels?) That user won't be able to have a
libpcreposix-0 that points to libpcre-0.dll and another than points to
libpcre-1.dll (because the libraries will no longer work if simply renamed).
>> 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)
>>
The coff file was something I added to Makefile.in. I was looking for
where to put it the new build process and one of you guys said it should
be made a part of the build process since it could be easily added if I
gave the commands needed. Those messages are in the archives.
>> 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).
>>
>>
I don't really care too much if the coff functionality is not made
available to everyone, though I do not want to have to use the Microsoft
toolchain myself to get it. Windres is part of the Gnu toolchain. If you
can provide a makefile.in that allows me to add my own coff file(s),
I'll be happy. Or if turns out to be easily added when/if
--alternate-win32-dll-names is done it is something that Windows users
will appreciate (and would certainly be nice for me if the version
numbers and strings came from build variables). I know that Philip said
he did not want 7.1 to remove functionality for Windows users. He also
didn't want to wait to see how CMake was going to pan out in this
regard. Since I've discovered that I can use those few extra commands to
get what I want in 7.1, its really the rest of the Windows user
community that's affected. So my vote would be, add a configure option
that creates shared libraries that are functionally compatible with 7.0.
If easily done, creation and linking of a coff file.
>> 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"
>
That part is from the "strings", there is also a version section.
>
> 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
>
>
>
When I first started making the coff file, I researched and learned that
an app *can* make use of the info (although I admit that ours does not).
But speaking strictly as a user, it is helpful to have it, even when
only informational in value. Sometimes an installer replaces my updated
library with an old version, and having that resource info makes it easy
for me, as a user, to deal with it. It is also beneficial to have the
copyright/license info user-accessible.
Regards,
Sheri
