Bob Rossi wrote:
> On Fri, Apr 06, 2007 at 01:51:50AM -0400, Sheri wrote:
>
>> Sheri wrote:
>>
>>> I have not had a reply from Alan about using the 2 libraries files in
>>> our environment.
>>>
>>>
>> Alan was indeed able to link to the two libraries in question, and they
>> can both be parallel to our exe (which is not on the path). He points
>> out that our plugin is also looking for the other style lib names, a
>> potential hazard for the end-user. If given a choice he would prefer to
>> keep to a combined pcre.dll.
>>
>
> I do think that the names,
>
> $ ls ~/download/pcre/pcre-7.1-RC4/prefix-shared/bin/
> libpcre-0.dll libpcrecpp-0.dll libpcreposix-0.dll pcre-config
> pcregrep.exe pcretest.exe
>
> should change before we release. Either we should do this the unix way,
> where we actually have 0 be 7.1, or we should do it the windows way,
> libpcre.dll, and get the extra dll support working for version numbers.
>
> What does everyone else think? I know we've been through a lot of pain
> over this, but releasing a version of pcre that acts one way, and
> another version of pcre that acts another way could be very difficult on
> all the end users.
>
> Thanks,
> Bob Rossi
>
>
It never occurred to me that the "-0" might become "-7.1". That really
would be awful on Windows. For new releases, it would never be possible
to independently update the shared libraries.
Bob, I posted a zip of the coff resources a few days ago, did you see it?
Also, I still don't understand the benefit of segregating posix in a
separate library? (BTW, there was a separate pcreposix.dll output by 7.0
and prior make's. But I think it included all the stuff on which it
depend from real pcre. The new libpcreposix-0.dll does not, so both
libpcreposix-0 and libpcre-0 would be needed by those using posix-only
api, as well as by those using both apis.)
Bob you say you don't want posix functions in the pcre shared library
because you don't use them. I don't think you use the shared library
anyway, but isn't it true that unless you #included pcreposix.h in your
application, you would not be accessing those few functions at all? As I
pointed out previously, my pcre.dll (with posix and coff) is actually
smaller than libpcre-0.dll (without posix).
Posix just adds four names to the library (which depend on their "real"
counterparts to work): regcomp, regerror, regexec, and regfree.
Here is what Alan says our code is presently doing:
> My code does the following:
>
> Loads pcre.dll. First looks in <powerpro installation>\plugins, then
> in <powerpro installation>, then on path. If it fails, complains
> bitterly.
>
> If succeeds, tries to load all known pcre api function entry points
> (pcre_compile etc). If it fails, complains bitterly.
>
> If succeeds, tries to load all known posix api function entry points
> (regcomp etc).
>
> If it fails, tries to load pcreposix.dll (search as above). If fails,
> complains bitterly.
>
> If succeeds, tries to load all known posix api function entry points
> (regcomp etc) from pcreposix.dll.
>
> I just tested your pcre.dll; no problem.
>
[he's talking about one I made for 7.1 RC4 using those additional
commands from the old make file.]
> libpcre-0.dll renamed pcre.dll works but lacks posix stuff,
> obviously.
>
> libpcreposix-0.dll (renamed or not fails because it depends on
> libpcre-0.dll, and can't find it because I renamed it.)
>
> Okay, so new version, attached, will try for pcre.dll. If
> successful, carries on as above.
>
> If it fails to find one, will try for libpcre-0.dll. If it finds one
> goes through same rigamarole as above, but if libpcre-0.dll has no
> psix api, goes for libpcreposix-0.dll. Works on my machine, but not
> throrougly tested.
>
> If you want to support this option, needs to be carefully thought
> through and carefully documented. Suppose someone has a pcre.dll on
> path and a libpcre-0.dll in plugins folder (at moment, pcre.dll takes
> precedence, no matter where it is; the toing and froing if I try to
> give libpcre-0.dll precedence just because it's in plugins folder
> gets nightmarish).
Regards,
Sheri
