On Saturday 30 December 2006 00:34, Max Lynch wrote:
> I am trying to get a library (libgpod) to compile on windows without
> cygwin, using mingw. =C2=A0I've installed libgw32c and all the headers, .=
So, you no longer have a clean, and stable MinGW installation; you have=20
contaminated the header pool with all of the GnuWin32 extensions, to the=20
extent that no header will be recognisable as a MinGW original.
> I am linking with -lgw32c and using their standard headers, but I want to
> think that this is a problem with libc and mingw.
Well, MinGW uses MSVCRT, with a few well chosen extensions; it does *not* u=
libc at all, and, while libgw32c is an extension library designed to work=20
with MinGW, it is neither provided by, nor supported by the MinGW project. =
As Tor (Lillqvist) has pointed out, if you need to use it at all, then you=
need to raise any support issues directly with the GnuWin32 project.
> I am using the "stable" gcc packages.
=46rom whence? If you mean our `Current' packages set, with headers replac=
those from GnuWin32, then it's no longer a pure MinGW installation, and I'm=
sorry, but I'm not prepared to attest to its residual `stability'.
> Any ideas? =C2=A0Thanks.=20
I'd like to second Tor's advice to avoid libgw32c, unless you *absolutely*=
can't get by without it. With no disrespect intended to Kees Zeelenberg,=20
(who maintains GnuWin32), I dislike the way in which he modifies the standa=
MinGW headers; therefore, in my own porting work for MinGW, I don't use=20
libgw32c, and I have never found a burning need for it. That said, I do fi=
some pre-built GnuWin32 binary packages to be extremely useful, in the=20
absence of any existing mingwPORT, or other more direct native MinGW build.
Other than this, I'm afraid I can offer no enlightenment, beyond those=20
suggestions already tabled by Tor.