Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
From: Tor Lillqvist <tml AT iki DOT fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15008.47435.442000.846182@gargle.gargle.HOWL>
Date: Sat, 3 Mar 2001 11:28:43 +0200 (FLE Standard Time)
To: "David A. Cobb" <superbiskit AT home DOT com>
Cc: Cygwin General MailList <cygwin AT cygwin DOT com>
Subject: Re: What's such a big deal about MSVC
In-Reply-To: <3A9FB1E6.FDE781B5@home.com>
References: <3A9FB1E6 DOT FDE781B5 AT home DOT com>
X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid

David A. Cobb writes:
 > I see several packages, GTK+/Win32 being on my mind at the moment, for
 > which the author advises they _must_ be compiled with MSVC.

Umm, no, GTK+ can be compiled either with gcc or MSVC. I use gcc when
building all of GLib, GTK+ and GIMP. The same goes for GTK+-using
code. The point you might be referring to is that, if you compile
GTK+-using code using gcc, and intend to use the prebuilt DLLs I
provide, you *must* use the -fnative-struct switch. Otherwise your
code will use different alignment for some struct fields, with
disastrous results. 

I want the same DLLs to be useable both from gcc- and MSVC-compiled
code, which is why they are compiled with this -fnative-struct switch.

(You most probably also should use -mno-cygwin when building code to
use the prebuilt GLib and GTK+ DLLs. As has been brought up on this
list countless times, unless you know exactly what is happening, you
will get into trouble if you mix different C runtimes in the same
program, in the application EXE and DLLs.)

As for rebuilding GLib and GTK+ yourself as Cygwin-using DLLs, that's
another matter. I have received some patches to GLib to enable this,
and added more stuff to make it possible to use the auto*/libtool
mechanism also to build GLib for "pure" Win32. I have sent a diff to
the gtk-devel list, but no comments so far. Also, some enhancements
are needed to libtool to make everyghin go smooth.

 > Part of the reason, evidently is some MSVC????.DLL that gets
 > included.

Msvcrt.dll is the current C library bundled with Windows. (Except with
the original Windows 95, but even for those still running that, you
will most probably get msvcrt.dll as soon as you install about any
recent software.)

 > So, what's the trick?  What funny backdoor is M$ exploiting with this?

You are being too paranoid here. Using msvcrt.dll on Windows is no
stranger than using the vendor-supplied proprietary C library on
Solaris or HP-UX.

 > In other words, what would it take to allow Cygwin to provide whatever
 > functionality this beast is giving?

You are misunderstanding. Cygwin isn't missing anything (in relation
to this issue). When starting my port of GIMP (thus first GLib and
GTK+) to Windows, I chose not to use Cygwin not because it would be
missing something (the port would have been a bit simpler if I could
have relied on Cygwin), but, as it seemed to be quite possible to do
without Cygwin, why then require the extra overhead?

Also, there is the licensing issue. GLib and GTK+ and licensed under
the LGPL, while Cygwin is GPL. I didn't want to restrict GLib and GTK+
on Windows to GPL programs.

--tml


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple