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.
> 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.
> 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.
--Daniel
--
NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef?
EMAIL1 = skunk@??? ## don't smell bad--- (/o|o\) /
EMAIL2 = skunk@??? ## it's the people who < (^),>
WWW = http://www.******.org/ ## annoy them that do! / \
--
(****** = site not yet online)
