This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: PCRE package for consideration
- From: Ronald Landheer-Cieslak <ronald at landheer dot com>
- To: Charles Wilson <cwilson at ece dot gatech dot edu>
- Cc: cygwin-apps at cygwin dot com
- Date: Fri, 2 May 2003 10:44:14 +0200 (CEST)
- Subject: Re: PCRE package for consideration
Chuck,
Thanks for reminding me about this.
For the moment, I have no idea who, other than the people I work with
here, will be using a MinGW version of pcre, but the people I work with
here will expect to be able to use it with MSVC w/o problems, which means
the ON_WINDOWS stuff is there to stay.
OTOH, I do maintain a MSVC6 project & workspace file for PCRE as well
(*please* don't ask why)..
Anyway, the ON_WINDOWS stuff will stay around at least for the time being.
I've tested your patch and Gerrit's on the PCRE I have here and will put
it on my site ASAP (I'll let the list know when it's there)/
thanx again :)
rlc
On Wed, 30 Apr 2003, Charles Wilson wrote:
>
> Ronald Landheer-Cieslak wrote:
> > I'll apply the patch, test it and report back.
> >
> > If all this works, I'll also ask mr Hazel to relibtoolize and see whether
> > the same thing also works on MinGW (if so, consider the ON_WINDOWS crap
> > gone).
>
> Now, let's not be hasty. While my patch *should* enable pcre to build
> properly on mingw -- assuming your MSYS environment has up-to-date
> autotools -- it relies on auto-import.
>
> Auto-import works fine on both cygwin and mingw.
>
> However, on mingw there are a few compatibility issues that one should
> consider. DLLs which rely on auto-import under mingw are NOT compatible
> with MSVC or BorlandC development -- only the GNU linker understands
> auto-import. (Just to avoid confusion:
>
> --------------------------
> On machine A, you have mingw/MSYS installed, and build
>
> libfoo-0.dll
> a mingw DLL which utilizes auto-import. It is created using
> MSYS/mingw tools.
>
> bar.exe
> a mingw app which is created using MSYS/mingw tools. It is linked
> against libfoo-0.dll.
>
> No problems. bar.exe runs like a champ. You then copy libfoo-0.dll
> and bar.exe over to machine B. On machine B, you only have MSVC; no
> mingw tools at all.
>
> You can RUN bar.exe with no problems.
>
> Now, you copy the source code for bar.exe from machine A to machine B --
> and try to rebuild the app using MSVC, linking against the already-built
> libfoo-0.dll.
>
> No can do. MSVC doesn't understand the dll's export table.
> ----------------------------
>
> Since the whole point of mingw is an interoperable (but free
> beer/speech) compiler on windows, the decision to create a "port" of a
> library using auto-import should be carefully considered.
>
> On cygwin, though, no such worries attest. We're happily independent of
> MSVC/Borland's linker and don't need to worry about their lack of
> capability in this regard.
>
> So, while this is a porter/maintainer decision, there are good reasons
> to keep the "ON_WINDOWS" gobbledy-gook for mingw, IF you wish. (But on
> cygwin -- go ahead, use auto-import. C'mon in, the water's fine.)
>
> --Chuck
>
>