Re: [pcre-dev] More Windows-related/misc. tweaks

Daniel Richard G. wrote:
> Hi Sheri,
>
> On Wed, 2007 Aug 15 16:17:55 -0400, Sheri wrote:
>
>> I assume testing RC4 also has the same changes. Unfortunately it didn't
>> solve my callout problem. Callouts still crash when returning result to
>> PCRE. I do not have the source code for our application. The programmer
>> says he doesn't include the h files, he "copied and pasted all the
>> #defines, and define pointers to functions equivalent to all function
>> declarations." So it seems my idea that changing h files might somehow
>> fix it is apparently false.
>>
>
> Could you ask your developer to put together a small test program that
> reproduces the crash? In order to address this problem, I'm going to need
> to get my hands on it. I have no idea offhand what it might be to suggest
> another fix.
>
That probably won't happen soon, but if and when I get it, will send to
you. Thank you very much for the offer.
>
>> There has been another side effect of changes made in building pcre 7.3.
>> Previously after building 7.1 and 7.2, I was able to process a few
>> additional commands gleaned from the old 7.0 build process to create the
>> combined shared Windows library pcre.dll (which has both pcre and
>> pcreposix, and to which I added coff data so the library version is
>> revealed in Windows file explorer). Those added commands no longer work.
>>
>
> This is something that can still be looked into. I missed the big
> discussion on this a couple of months back, but the necessary sequence of
> commands is known.
>
>
>> The end result of that process (in Msys/MinGW) now gives this:
>>
>> Creating library file: .libs/libpcre.dll.a
>> .libs/libpcre.a(pcreposix.o):pcreposix.c:(.text+0xec): undefined
>> reference to `_imp__pcre_free'
>> .libs/libpcre.a(pcreposix.o):pcreposix.c:(.text+0x161): undefined
>> reference to `_imp__pcre_compile2'
>> .libs/libpcre.a(pcreposix.o):pcreposix.c:(.text+0x194): undefined
>> reference to `_imp__pcre_info'
>> .libs/libpcre.a(pcreposix.o):pcreposix.c:(.text+0x25b): undefined
>> reference to `_imp__pcre_exec'
>> collect2: ld returned 1 exit status
>>
>
> This isn't a failure of the COFF-metadata commands, however; this is just a
> flat-out link failure. And I see what is going on here: pcreposix.o is
> looking for pcre_free() et al. out of a DLL (hence the "_imp__" prefix),
> but because pcreposix.o is inside the pcre library here, it's not going
> through the DLL interface, and can't find those functions.
>
> It is an error for pcreposix.o to be present in libpcre.a. pcreposix is a
> separate library in its own right, that depends on pcre.
>
OK, maybe I could quit trying to combine them and produce libpcre-0.dll
and libpcreposix-0.dll each with their own coff data if nothing else.
Possibly I could also name them as I would want (pcre.dll and
pcreposix.dll), all using similar add-on commands to what I used
previously. I'll experiment and report back.
>
>> Use of a combined pcre.dll with coff data continues to be our preference
>> even though the standard names can work. Users would have to delete
>> pcre.dll before our app even sees libpcre-0.dll and libpcreposix-0.dll,
>> and the accessed libraries would be subject to getting downgraded during
>> installation/reinstallation.
>>
>
> libpcre-0.dll and libpcreposix-0.dll are Libtool creations; I agree that
> pcre.dll is preferable. Have you tried using the CMake system on Mingw?
> That might just do the trick, if not yet to the point of adding the COFF
> metadata bits.
>
>
I'd be happy to try it, but would need some guidance and hand holding :D

Regards,
Sheri