RE: [Glade-devel] RE: Win32 port of GTK+2.6.1
- From: "Cui, Fanzhe" <fanzhe cui intel com>
- To: "Tor Lillqvist" <tml iki fi>
- Cc: gtk-devel-list gnome org, Ivan Wong <email ivanwong info>, glade-devel lists ximian com
- Subject: RE: [Glade-devel] RE: Win32 port of GTK+2.6.1
- Date: Wed, 12 Jan 2005 14:38:13 -0000
Tor,
I think I going to try with the suggestion that I made. Personally I
think the info you provided is very helpful, and I think some other
users developing system with MS VC++ 7.xx could have the same issue. If
we have tips or documents addressing such issue, it could be beneficial
to others.
Regards,
Fanz
-----Original Message-----
From: Tor Lillqvist [mailto:tml iki fi]
Sent: Wednesday, January 12, 2005 4:19 AM
To: Cui, Fanzhe
Cc: Ivan Wong; Tor Lillqvist; glade-devel lists ximian com;
gtk-devel-list gnome org
Subject: FW: [Glade-devel] RE: Win32 port of GTK+2.6.1
Cui, Fanzhe writes:
> I built the project of gtk-demo (I call it gtk-demo_win32) with MS
> VC++ 7.3, and most of them are working except a couple of things.
Remember that file descriptors (the small numbers returned by open()
etc, and also stored inside FILE structs) are local to the C
runtime. They are not known to the Windows kernel, like file
descriptors in Unix. You cannot pass file descriptors (and thus by
extension FILE structs) between .exes/.dlls that use different C
runtime and expect it to work.
If you use MSVC 7.x, the code you produce most likely uses the
MSVCR7*.DLL C runtime (or even worse, static C library). If you have a
GLib that built with mingw, it uses the MSVCRT.DLL C runtime. I.e. the
FILE* that g_fopen() returns won't work in stdio calls in your
code. (Or it might work completely wrong, i.e. if you g_fopen() a
file, the file descriptor used might be in use for some completely
other file in your code, causing very odd things to happen, possibly
corrupting important files.)
You should rebuild your code to use MSVCRT.DLL. Do a Google search; I
am sure that somebody has figured out how to coerce MSVC 7.* to do
this. If not, use mingw. Or find a copy of the old but reliable (at
least for C) MSVC6 (and apply the SPs) and use that.
Also, as the MSVCR7*.DLL are not part of the operating system like
MSVCRT.DLL, it's against the (L)GPL to distribute (L)GPL software that
would use MSVCR7*.DLL. (I am not a lawyer, but this seems to be the
common interpretation of the situation.) Thus, now and in the
foreseeable future, (L)GPL software for Windows should continue to use
MSVCRT.DLL.
I strongly advice people who might still insist on building GLib, GTK+
etc themselves with MSVC 7.* and to use MSVCR7*.DLL to use different
names for their DLLs, to avoid confusion. The "standard" DLL names
that a mingw build produces should be used only for DLLs that use
MSVCRT.DLL. Otherwise there will be no end of confusion if and when
there starts to appear various distributions of GTK+ etc built to use
different C runtimes but using the same DLL names.
--tml
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]