This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
> 
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]