On Tue, Mar 20, 2007 at 12:17:26PM +0000, Philip Hazel wrote:
> . Somebody who knows about Windows needs to check out the NON-UNIX-USE
> file, especially the section entitled OUT-OF-DATE COMMENTS ABOUT WIN32
> BUILDS.
I'm not really sure cygwin would be considered non-unix-use.
OUT-OF-DATE COMMENTS ABOUT WIN32 BUILDS
Some help in building a Win32 DLL of PCRE in GnuWin32 environments was
contributed by Paul Sokolovsky. These environments are Mingw32
(
http://www.xraylith.wisc.edu/~khan/software/gnu-win32/) and CygWin
(
http://sourceware.cygnus.com/cygwin/). Paul comments:
I'm not sure if the above comments are helpful. Why not just tell users
about mingw.org and cygwin.com ? We should make it clear that there are
two totally separate options when building on windows. Using the mingw
gcc compiler or using the cygwin gcc compiler. These are not the same
beasts at all.
For CygWin, set CFLAGS=-mno-cygwin, and do 'make dll'. You'll get
pcre.dll (containing pcreposix also), libpcre.dll.a, and dynamically
linked pgrep and pcretest. If you have /bin/sh, run RunTest (three
main test go ok, locale not supported).
OK, the above is wrong now. We should make it clear, that the cygwin gcc
will generate libraries and executables that depend on cygwin1.dll.
Cygwin requires users to distribute the cygwin1.dll, which is under the
GPL license, which forces not only pcre to be under the GPL if they use
it, but also there entire application. That is of course, unless they
choose to purchase a license of cygwin from redhat which allows them
to keep there code proprietary. That's for starters.
Mingw gcc has no such restrictions. The mingw gcc will generate a
library or executable that can run standalone on windows with out
any 3rd party dll or licensing issues.
Now, if the user uses the -mno-cygwin cygwin gcc flag, what that really
does is to tell cygwin's gcc to use the mingw gcc. cygwin's gcc is only
acting as a front end to mingw's gcc. See, if you install cygwin's gcc,
you get both cygwin's gcc and mingw's gcc.
Phew. That was a lot of describing. So, the user can build native
binaries by using mingw/msys or by getting cygwin and using -mno-cygwin.
The user can build binaries that depend on cygwin1.dll by using cygwin
with the normal compiler flag they want.
Either way, there are no longer special flags that need to be used like
described above. 'make dll' doesn't exist as long as I know. A simple
./configure && make && make install
will work on both cygwin and mingw.
Changes to do MinGW with autoconf 2.50 were supplied by Fred Cox
<sailorFred@???>, who comments as follows:
If you are using the PCRE DLL, the normal Unix style configure && make &&
make check && make install should just work[*]. If you want to statically
link against the .a file, you must define PCRE_STATIC before including
pcre.h, otherwise the pcre_malloc and pcre_free exported functions will be
declared __declspec(dllimport), with hilarious results. See the configure.in
and pcretest.c for how it is done for the static test.
Also, there will only be a libpcre.la, not a libpcreposix.la, as you
would expect from the Unix version. The single DLL includes the pcreposix
interface.
I also don't think the above comments are any longer necessary.
Actually, the part about PCRE_STATIC is, but that's it. I have to
#define PCRE_STATIC in my software to link against pcre on mingw.
[*] But note that the supplied test files are in Unix format, with just LF
characters as line terminators. You will have to edit them to change to CR LF
terminators.
Wow! Maybe this is why the test suite failed. What can be done about
this? We really should fix this so that it Just Works for users.
Thanks,
Bob Rossi
