Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive:	<http://sourceware.cygnus.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help:	<mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender:	cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To:	mailing list cygwin AT sourceware DOT cygnus DOT com
Message-Id:	<199911081901.NAA13399@mercury.xraylith.wisc.edu>
To:	Tor Lillqvist <tml AT iki DOT fi>
cc:	cygwin AT sourceware DOT cygnus DOT com
Subject:	Re: [ANN] GCC-2.95.2 binaries for Cygwin b20.1
In-Reply-To:	Your message of "Mon, 08 Nov 1999 15:19:01 +0200."
	<14374 DOT 52677 DOT 20000 DOT 857145 AT gargle DOT gargle DOT HOWL>
Date:	Mon, 08 Nov 1999 13:01:29 -0600
From:	Mumit Khan <khan AT thor DOT xraylith DOT wisc DOT edu>

Tor Lillqvist <tml AT iki DOT fi> writes:
> 
> In my work on GLib, GTk+ and the GIMP for Win32, I want to run gcc etc
> under cygwin, but still produce EXEs and DLLs that run without cygwin,
> and with the MSVCRT runtime, even. I don't want to use gcc packaged
> for mingw32. (There are some irritating differences in the way command
> line arguments are passed to gcc from Makefiles, for instance.)
> 
> In order to do this I have to to the following with gcc 2.95.2. (This
> is in a "recipe" form as I intend to use the same text as advice to
> others wanting to build GLib, GTk+ and the GIMP on Win32 with gcc)
> 
> I would appreciate comments on the correctness of this, and whether it
> would be possible to have support for building MSVCRT-using binaries
> with gcc-on-cygwin "built in" in the future...

Yes, it should work fine, but the mingw-extra package needs to be updated
to MSVCRT as well.

> 
> BTW, there seems to be a slight incompatibility between gcc-2.95.2 and
> dlltool 2.9.4: If you export a variable with __declspec(dllexport),
> gcc produces a " -export:foo,data" directive. Dlltool mistakes this to
> mean that also a symbol "data" is exported. This can be worked around
> by not exporting data with __declspec, only with a .def file.
> Gcc-2.95 didn't add the ",data" part.

Thanks for reminding me of this! I had forgotten the fact that I don't
normally distribute binutils 2.9.4 binaries. I'll upload a modified
binutils-2.9.4 build sometime today to:

  ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/cygwin/gcc-2.95.2/

and make a note of it in the Known problems list. The diff, by the way,
is already available at:

  ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/cygwin/gcc-2.95.2/patches/

area.

I'll comment on your -mno-cygwin+MSVCRT issue later when I get some time
to read through it.

> 
>    This enables building the profiling gcrt2.o. I don't know how useful
>    it is, though, there doesn't seem to be any gprof command in cygwin.

My binutils-2.9.4 tree has gprof.

> 
>    This fixes a typo in wingdi.h:
> 
> ================ cut here ================
> diff -ru2 ./w32api/include/wingdi.h ../../src/mingw-runtime-19991107/w32api/i
> nclude/wingdi.h
> --- ./w32api/include/wingdi.h	Thu Nov 04 03:42:40 1999
> +++ ../../src/mingw-runtime-19991107/w32api/include/wingdi.h	Mon Nov 08 12:4
> 8:02 1999
> @@ -304,5 +304,5 @@
>  #define FW_BOLD	700
>  #define FW_EXTRABOLD	800
> -#define FW_ULTRABOLD	FW_EXTRABOOLD
> +#define FW_ULTRABOLD	FW_EXTRABOLD
>  #define FW_HEAVY	900
>  #define FW_BLACK	FW_HEAVY

Yikes. Fixed, thanks.

> 
> ================ cut here ================
> 
>    (I haven't checked yet if other small errors I have noticed in
>    previous w32api header versions have been corrected.)

Please do. This will help tremendously.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -