Hi Philip,
I think you should look at this
http://msdn2.microsoft.com/en-us/library/ms235460(vs.80).aspx
Although it is talking about use of microsoft's products, I'm sure the
shared/dll concept is the same when a dll is created with libtool.
The linking that occured in the old-style make somehow addresses the
issue (at least with respect to pcretest.exe, the way I create it)
I have now succeeded in building a working RC3 using the old-style make.
This is how I did it:
1. Ran my configure command with all my usual options in pcre-7.0.
2. Ran same configure command in pcre-7.1-RC3
3. copied makefile and makefile.in from pcre-7.0 to pcre-7.1-RC3
4. edited both of the above to change ucptable.c to ucptable.h
5. ran make in pcre-7.1-RC3. There were numerous warnings about various
things that were already defined. But nothing fatal happened before the
dll was produced. In fact, I think I got all the shared and static
libraries (despite having asked only for shared, and no cpp.)
6.Created pcretest.exe manually, and ran RunTest.bat; everything
compared favorably except french locale. It has the "no match" issue
with my "any" newline test case.
If that microsoft page is meaningful to you, maybe the solution will
become apparent, as to how you could modify pcretest to call the library
for all needed memory functions (without passing pointers, etc.)
I will try your pcre_compile mod later though, if after viewing the
microsoft page you still think it would be helpful.
Concerning a windows expert, who put together the windows/msys part of
the original makefile process? Maybe there is a good reason it doesn't
use libtool?
Also, when comparing the .libs dir created by my hodgepodge make vs one
from the new make, I see pcre.dll-def (nothing similar in the new style
.libs). This is the content of pcre.dll-def (look esp. at pcre_malloc
and pcre_free) and this file is utilized in the part of the makefile
that produces pcre.dll.
EXPORTS
_pcre_OP_lengths @1 DATA
_pcre_default_tables @2 DATA
_pcre_is_newline @3
_pcre_ord2utf8 @4
_pcre_try_flipped @5
_pcre_ucp_findprop @6
_pcre_ucp_othercase @7
_pcre_utf8_table1 @8 DATA
_pcre_utf8_table1_size @9 DATA
_pcre_utf8_table2 @10 DATA
_pcre_utf8_table3 @11 DATA
_pcre_utf8_table4 @12 DATA
_pcre_utt @13 DATA
_pcre_utt_size @14 DATA
_pcre_valid_utf8 @15
_pcre_was_newline @16
_pcre_xclass @17
pcre_callout @18 DATA
pcre_compile @19
pcre_compile2 @20
pcre_config @21
pcre_copy_named_substring @22
pcre_copy_substring @23
pcre_dfa_exec @24
pcre_exec @25
pcre_free @26 DATA
pcre_free_substring @27
pcre_free_substring_list @28
pcre_fullinfo @29
pcre_get_named_substring @30
pcre_get_stringnumber @31
pcre_get_stringtable_entries @32
pcre_get_substring @33
pcre_get_substring_list @34
pcre_info @35
pcre_maketables @36
pcre_malloc @37 DATA
pcre_refcount @38
pcre_stack_free @39 DATA
pcre_stack_malloc @40 DATA
pcre_study @41
pcre_version @42
regcomp @43
regerror @44
regexec @45
regfree @46
Regards,
Sheri
Philip Hazel wrote:
> On Thu, 29 Mar 2007, Sheri wrote:
>
>
>> I compiled your pcretest.c using 7.0 headers, 7.0 pcre_tables.c and 7.1
>> print*.src, then linked it against 7.0 pcre.dll.
>>
>> I get this lovely output.
>>
>
> Good, but not surprising, since we know that the 7.0 pcre.dll works.
>
>
>> Also tried building 7.1 RC3 with at least malloc and free altered in
>> pcre_globals.c. Saw some warnings about returning things for voids.
>> Tried the pattern in pcretest (libraries and pcretest compiled and
>> linked by new style configure/make) and nothing changed, still malloc
>> was zero.
>>
>
> We really do need an expert in Windows compiling and linking here.
>
>
>> =============================
>> pcre_malloc set to 00402965
>>
>
> OK, I suppose we could check that that same value is getting passed into
> pcre_compile(). If you look around line 5080 in pcre_compile.c, you will
> find these lines:
>
> ----------------------------------------------------------------------
> uschar cworkspace[COMPILE_WORK_SIZE];
>
>
> /* Set this early so that early errors get offset 0. */
>
> ptr = (const uschar *)pattern;
> ----------------------------------------------------------------------
>
> After the first of those lines, add this one line:
>
> fprintf(stderr, "pcre_malloc set to %p\n", (void *)pcre_malloc);
>
> Re-compile, and run the test again. If all is well, the two lines that
> say "pcre_malloc set to" should give the same value. I predict that they
> won't. If I'm right, that's the problem - but WHY? If I'm wrong, it's
> even more mysterious.
>
> Philip
>
>
