Bob Rossi wrote: > On Wed, Apr 04, 2007 at 12:21:49AM -0400, Charles Wilson wrote:
>
>> Bob Rossi wrote:
>>
>
>> I noted a few issues with the windows port:
>>
>> 1) the posix emulation was linked directly in to the "main" library.
>> Personally, I preferred for the windows port to be more like the *nix
>> ones, with separate libraries. So my changes were done with that goal
>> in mind.
>>
>
> When you build pcre-7.1-rc3 on mingw as a shared library, you currently
> get,
>
> $ ls shared/bin
> libpcre-0.dll libpcrecpp-0.dll libpcreposix-0.dll pcre-config
> pcregrep.exe pcretest.exe
>
> So, I think that already is doing what you wanted. That's 1 step in the
> correct direction.
>
> Natch, we liked it as it was, with pcreposix functions included. Our app
is a dll plugin for a Windows exe. The plugin lives in an old version of
Microsoft C++. The (installed) exe has a subdirectory for plugins. Even
though it is linked to our plugin dll we are not able to keep the
pcre.dll in the plugins dir, it doesn't work unless parallel to the exe
or on the path. Well parallel to the exe was fine and worked, and all
the functions were in one dll when configure/make was used with
msys/mingw. Then I went through an exercise with Interix and wgcc to try
making pcre libraries through the straight Unix configure/make but
cross-compiling with the Microsoft compiler. This did not work for VC6
compiler so I tried it with VC8 (Express). I am a user-type, so this was
all rather difficult; plus my friend who programs the plugin wanted to
stay with his established environment (VC6). With help from the author
of wgcc, I did finally make the libraries. There were problems with the
runtime in trial linkage to the VC6 application. Furthermore, the dlls
output from the process had posix vs native functions in separate dlls.
It didn't work with both of the them parallel to the exe application.
One of them had to be on the path, instead. That would have caused a
serious change for user installation, upgrade and removal procedure.
So I hope to avoid that issue if at all possible, by keeping the native
and posix functions combined into one pcre.dll. The plugin itself has
old functions that use the posix api, and new ones that exploit the
native api.
