On Sun, 22 Jan 2012, Philip Hazel wrote: > What I don't know is whether building PCRE under Windows using one of > the standard methods (i.e. "configure" or "cmake") works. I rather > suspect that it won't. *That* is why I think changes are needed.
I think this issue would hinder a Windows build only if that library is built as a DLL. In a more conventional non-DLL build the resulting ".lib" would contain all the code and data that you'd expect to see in a Unix build. Linking pcretest plus pcre_printint plus the library would resolve the tables using the pcre_tables compilation that's in the library. That's my guess anyway. Tomorrow I hope to have time for some RC1 evaluation. If it's not in the trunk yet then I'll use Zoltan's patch to see what happens. I'm guessing it's already verified, and in any case equalizing the PRIV() seems like a sure bet to circumvent what was encountered. Adjusting just documentation or the code, I'm happy with either one. This was tiny considering the extent of changes that must have been required to enable the option of 16-bit data matching. Thanks, and also to Zoltan. Regards, Graycode -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
