Philip Hazel wrote:
> On Mon, 2 Apr 2007, I wrote:
>
>
>> On Fri, 30 Mar 2007, Sheri wrote:
>>
>
>
>>> 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.
>>>
>> *That* may well be relevant. I see that there is a file called pcre.def
>> in the current distribution containing the same as yours except for
>> those names beginning with underscore (which should not be generally
>> exported). Maybe it isn't getting used properly in the new regime?
>>
>> Maybe it isn't getting included in the build? I'll check that too.
>> More later.
>>
>
> It seems that the file pcre.def, which was included in 7.0
> distributions, is not currently in the 7.1 distribution. I wonder if
> that is all that is necessary? I see that the configure script does make
> some use of it.
>
> Sheri: Please can you try getting a clean 7.1-RCx distribution, copy
> into it the file pcre.def from a 7.0 distribution, and see if that does
> anything for you. If not, there are also two files called libpcre.def
> and libpcreposix.def, though they just contain subsets of what pcre.def
> contains, so I'd like the test first just to have pcre.def, please.
>
>
Hi Philip,
I did it both ways, first with addition of pcre.def file, then with all
three def files present in the RC3 dir. Each time started fresh. The end
result each way is that pcretest still has all those memory
disagreements. So the mere presence of the def files has no effect at
all. Make is not using them per my console output (whereas it did in 7.0).
> The URL wasn't particularly helpful, but I did find
>
> http://msdn2.microsoft.com/en-us/library/28d6s79h.aspx
>
> which talks about .def files. However, I find from there this:
>
> In newer compiler versions, you can export data, functions, classes,
> or class member functions from a DLL using the __declspec(dllexport)
> keyword. __declspec(dllexport) adds the export directive to the
> object file so you do not need to use a .def file.
>
> and I note that pcre.h does have the --declspec magic.
>
> I am learning more about Win32 that I really want do. :-)
>
I know how exactly how you feel :D
It sounds like it will be awhile yet before the Cmake approach supports
shared dlls for Windows. I hope (but never expect) anything new to go
smoothly.
Regards,
Sheri
