Re: [pcre-dev] Mingw Memory mismatch problem

On Wed, 4 Apr 2007, Bob Rossi wrote:

> That successfully built the pcre shared libraries, and I was able to run
> pcretest as described by Sheri. So this fixes the problem. Good job!

Hurrah! Hurrah! Sighs of relief. But I'll still wait anxiously for Sheri
to confirm...

> I still can't run 'make check', as it hoses my terminal and never
> returnes. What's up with that?

Have you tried running the tests individually? That is:

./RunTest
./RunGrepTest
./pcrecpp_unittest
./pcre_scanner_unittest
./pcre_stringpiece_unittest

If they run on their own, then it's the setting up of them in the
Makefile that is the problem. Given that pcretest runs for you, I'd be
surprised if RunTest won't run on its own.

> Now, we should probably link that dll to a small program using Visual
> C++. What would be an easy way to do this? Write a small C program that
> links to the dll using the import lib?

Well, the pcredemo program gets built already. If you want to try what
happens after installation, you could try rebuilding that by hand in
some other directory, as if you were an application developer. :-)

> One other note, Sheri doesn't seem to like that pcre-7.1 generates 3
> dll's instead of 1 compared to pcre-7.0. I haven't verified that 7.0
> generates one, but I'm taking his word for it. I actually prefer the 3
> dll's as it seems cleaner. For instance, I disable cpp support and I
> don't use libpcreposix. So I won't need to link that in at all. Either
> way, depending on what we do, you might want to add something to the
> ChangeLog or README to describe the change.

I agree with you about three separate libraries - not that it matters to
me, of course, as a non-Windows user - but it seems "cleaner". You are
right that I should note this in the docs.

I'll wait for reactions from others before proceeding - and as tomorrow
is busy for me and then it's Easter, I'll leave this till next Tuesday.
Then I would like to plough ahead and get a 7.1 release out the door as
soon as I can. After all, we can always put out more releases when other
changes are identified.

Philip

--
Philip Hazel, University of Cambridge Computing Service.