Daniel Richard G. wrote:
> On Wed, 2007 Aug 01 10:34:51 +0100, Philip Hazel wrote:
>
>> ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/Testing/pcre-7.3-RC2.tar.gz
>> ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/Testing/pcre-7.3-RC2.tar.bz2
>> ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/Testing/pcre-7.3-RC2.zip
>>
>> (Make sure you get the -RC2 and not -RC1 version - the latter was for an
>> OP to test a bug fix.)
>>
>> If people can test this on Windows, in as many environments as possible,
>> it would be good.
>>
>
> Sheri, this is for you :)
>
>
Hi Daniel,
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.
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.
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
These are the commands I've been using, in the build dir, after using make:
$ rm -f libpcre.la
$ /bin/sh ./libtool --mode=link gcc -export-symbols-regex '^[^_]' -I. \
-I. -rpath /usr/local/lib -version-info \
'0:1:0' -o libpcre.la pcre_chartables.lo pcre_compile.lo \
pcre_config.lo pcre_dfa_exec.lo pcre_exec.lo pcre_fullinfo.lo \
pcre_get.lo pcre_globals.lo pcre_info.lo pcre_maketables.lo \
pcre_newline.lo pcre_ord2utf8.lo pcre_refcount.lo pcre_study.lo \
pcre_tables.lo pcre_try_flipped.lo pcre_ucp_searchfuncs.lo \
pcre_valid_utf8.lo pcre_version.lo pcre_xclass.lo pcreposix.lo
$ gcc -O3 -s -shared -o .libs/pcre.dll pcre.coff \
-Wl,--whole-archive .libs/libpcre.a \
-Wl,--out-implib,.libs/libpcre.dll.a \
-Wl,--output-def,.libs/pcre.dll-def \
-Wl,--export-all-symbols \
-Wl,--no-whole-archive
My configure statement (processed prior to make) looked like this:
$ CFLAGS='-O3 -s' ../pcre-7.3-RC4/configure --prefix=$PWD/../prefix
--enable-utf8 \
--enable-newline-is-anycrlf --enable-unicode-properties
--disable-stack-for-recursion
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.
Regards,
Sheri
