Hi Daniel,
(Sorry resending as reply previously went private)
Daniel Richard G. wrote:
> Hi Sheri, sorry for not getting back to you sooner,
>
> On Sat, 2007 Aug 18 11:36:50 -0400, Sheri wrote:
>
>>> 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.
>>
>
> I'm happy to figure this one out, as it's a pretty serious bug. Just two
> things: (1) the program should be as minimal as possible, and (2) it should
> use PCRE libs built and linked in a standard way. (I remembered mention of
> a slightly odd way of linking the libraries to the app.)
>
>
It may not be possible to do what you ask. We operate under Windows, the
app is not linked to PCRE. We build shared libraries (until recently
only one shared library) for which we use LoadLibrary (dynamic linking
on Windows).
This is a shot in the dark, but over the weekend I succeeded in linking
coff data into the libraries and naming the libraries pcre.dll and
pcreposix.dll. I referred to libtool documentation (but mostly just
dummied a few add-on commands from what happened during Make).
I spotted this info in the libtool docs related to using autoconfig and
automake, which could be relevant to the failure of our callout data (I
have no idea how to research or implement the macro in question, all I'm
running are config (with my options) and Make).
================
Macro: AC_LIBTOOL_WIN32_DLL
This macro should be used if the package has been ported to build
clean dlls on win32 platforms. Usually this means that any library data
items are exported with __declspec(dllexport) and imported with
__declspec(dllimport). If this macro is not used, libtool will assume
that the package libraries are not dll clean and will build only static
libraries on win32 hosts.
This macro must be called before AC_PROG_LIBTOOL, and provision must
be made to pass `-no-undefined' to libtool in link mode from the package
Makefile. Naturally, if you pass `-no-undefined', you must ensure that
all the library symbols really are defined at link time!
=================
"No undefined" does appear to be getting processed in our linkage, (what
happens when I Make).
>>> 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.
>>
>
> This is what the CMake system does (pcre.dll and pcreposix.dll). Should be
> straightforward.
>
>
>>> 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
>>
>
> Not a problem! Here's a step-by-step:
>
> 1. Assume that the PCRE source tree is in C:\devel\pcre\, C:\tmp\ is
> available, and CMake is downloaded (http://www.cmake.org/), installed,
> and in the PATH.
>
> 2. Create a new, empty build directory: C:\tmp\pcre-build\
>
> 3. Run CMakeSetup
>
> 4. Enter C:\devel\pcre and C:\tmp\pcre-build for the source and build
> directories, respectively
>
> 5. Hit the "Configure" button.
>
> 6. Select the particular IDE / build tool that you wish to use (Visual
> Studio, MSYS makefiles, MinGW makefiles, etc.)
>
> 7. The GUI will then list several configuration options. This is where you
> can enable UTF-8 support, etc.
>
> 8. Hit "Configure" again. The adjacent "OK" button should now be active.
>
> 9. Hit "OK".
>
> 10. The build directory should now contain a usable build system, be it a
> solution file for Visual Studio, makefiles for MinGW, etc.
>
>
Thank you, will give that a try in the next day or so just to see if
anything changes.
> Let me know if you run into any snags. CMake also has an ncurses tool
> (ccmake) and one for the command-line (cmake), but CMakeSetup is a
> friendly, mostly-polished tool that is good for first-time/infrequent use.
> Its availability, IMO, is a credit to the CMake project.
>
>
> --Daniel
>
>
>
Regards,
Sheri
