After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 141485 - GLib doesn't include makefiles for Microsoft tools
GLib doesn't include makefiles for Microsoft tools
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: win32
2.4.x
Other Windows
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
gtk-win32 maintainers
Depends on:
Blocks:
 
 
Reported: 2004-04-30 11:29 UTC by Steve Lhomme
Modified: 2011-02-18 16:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
This patch will allow compilation from both the IDE and the command-line (77.11 KB, patch)
2004-04-30 11:30 UTC, Steve Lhomme
none Details | Review
Source-only fixes (1.36 KB, patch)
2004-05-01 14:47 UTC, Steve Lhomme
none Details | Review
Same patch but working with nmake and commercial VC7 (2.72 KB, patch)
2004-05-01 15:33 UTC, Steve Lhomme
none Details | Review
Same patch with simplications from Tor (2.63 KB, patch)
2004-05-02 09:23 UTC, Steve Lhomme
none Details | Review
Same patch but reducing the size of the .dll/.exe produced (2.76 KB, patch)
2004-05-02 09:37 UTC, Steve Lhomme
none Details | Review

Description Steve Lhomme 2004-04-30 11:29:18 UTC
There is no makefiles to build GLib with MSVC7 (now available from free as a
command line compiler). And there are some compilation problems with these tools.
Comment 1 Steve Lhomme 2004-04-30 11:30:30 UTC
Created attachment 27227 [details] [review]
This patch will allow compilation from both the IDE and the command-line
Comment 2 Tor Lillqvist 2004-04-30 12:46:14 UTC
Hmm...

1) Are you sure that it is possible to build GLib to use msvcrt.dll using just 
the now freely available command-line compiler and tools? At least when I 
downloaded it, it didn't include any msvcrt.lib. I don't think we want to 
support building GLib with the compiler-dependent msvcr70.dll, as that would 
mean potentially masssive interoperability problems with code built to use 
msvcrt.dll (either using gcc or MSVC).

2) Instead of introducing a new subdirectory "win32-msvc7" in the "build" 
module, I would prefer to have just whatever changes are needed to work with 
MSVC7 added to the current "win32" subdirectory. Or is the main point of the 
diffs to the dirent files just to update the code to what's currently in mingw?

Anyway, at least in GLib 2.6, I think that the build/win32/dirent.* can go 
away, and instead we should have g_opendir_utf8(), g_readdir_utf8() etc 
functions in the GLib proper, and those would be implemented using the wide-
char versions of the C library directory API, and then return results in UTF-8. 
There is an enhancement request for this in Bugzilla.

3) Considering that the major MSVC-using GLib and GTK contributor, Hans Breuer, 
uses MSVC 5 (unless I am mistaken), do we really want to have separate 
makefiles and project files for MSVC7? Who is going to keep them maintained in 
the future? Wouldn't it be better to spend time to make sure the current 
makefile.msc files and the stuff in build/win32 work also with MSVC7?

4) Your project files seem to produce DLLs with a different name than those 
produced by a mingw build. For instance, libglib-2.0.dll instead of libglib-2.0-
0.dll. Is this on purpose, because they aren't binary compatible? If so, the 
names should differ even more, to avoid confusion. On the other hand, if they 
are binary compatible, they should use the same names for the DLLs.

5) The "build" subdirectory is actually a separate module in CVS, and it is (or 
at least used to be) included not only in glib but also in the gtk+ module. It 
shouldn't contain GLib-specific stuff, so the project files (if accepted at 
all) should be in GLib's directories.

6) What is the gstmarshal.h used for? gmarshal.h is produced with glib-
genmarshal, isn't it?
Comment 3 Steve Lhomme 2004-04-30 13:09:21 UTC
#1) These makefile don't make use of MSVCRT when built from the command line
version. They do when used with the IDE (as the DLL is available in this case).

#2) It is possible to put every file I added in that win32 dir, as long as
Makefile is renamed to something else.

The new dirent files make better use of TCHAR. For reason I don't remember the
ones in the original win32 dir didn't work with MSVC. Maybe the new one works
with MinGW32. IMO it should be kept (even renamed) as long as the other changes
are not done.

#3) I just checked the makefile.msc file and it's really not compatible with
MSVC7. And it seems to be using MS nmake while I'm using GNU make (it won't work
with GNU make on my system). So I suggest keeping a different makefile for each.
And I can maintain the code/files I submit. I will do the same for GStreamer
(that can now be built the same way).

#4) Are you sure of that ? Looking at the original makefiles it doesn't look
like that. They should be compatible so it would be better to have the same names.

#5) OK, great. I originally worked this way, until I noticed the build dir. But
maybe it's better to put the win32-msvc7 directory in the top GLib dir. As the
makefiles are GLib specific.

#6) Mistake on my side. It can be removed.

Should I submit a new patch with all said ?
Comment 4 Tor Lillqvist 2004-04-30 13:12:20 UTC
> Should I submit a new patch with all said ?

Maybe wait for some comment by Hans (and/or other interested parties) first.
Comment 5 Hans Breuer 2004-04-30 13:53:47 UTC
#1) not using msvcrt.dll (but the static will probably slightly break many
programs above GLib. It is possible to get e.g. Te GIMP to work if _all_
dependencies have been built against msvcrt71.dll. But redistributing them may
violate the GPL/LGPL.

#2) I suspect the use of TCHAR will break the mingw build (as it requires to
define UNICODE during the build. Everywhere else in gtk+ the widechar versions
of the SDK are used explicit - and not magically.

#3) maybe I don't understand you correctly, but the existing makefile.msc _do_
work with all versions of nmake (tested from vc5 to vc71 (aka .net 2003). AFAIK
there is no nmake included with the "free" vc2003 editidion. Maybe it is with
the 300+ MB platform sdk which I probably wont try to download ...

Also I've tried to explain elsewhere why I don't think it's a good idea to use
the GUI (and specific version bound) "makefiles" (recently renamed to solution
.sln :) at all. IMO this will be a maintainance nightmare - especially as they
are never downward compatible. At least with vc5 - vc6 it was possible to create
a project file which simply wrapped the exiting makefile.msc, i.e. IDE
integration without the compatibility price ...

Sorry to say : but to me this all looks like a WONTFIX
Comment 6 Steve Lhomme 2004-04-30 14:22:04 UTC
#1) OK, but there is no other way with the free version. Is that a license
problem ? If so, I don't see why using the static libraries would break the GPL
(and even more the LGPL) there are tons of Win32 GPL softwares that use it. And
the GPL doesn't prevent you from using proprietary code.

#2) That may mean that my DLLs are not compatible with yours (so it would be
good to use other names)

#3) No, I mean I don't use NMake. And your makefiles are for nmake (not free),
while mine are for GNU make (free). You prefer to stick to tools not available
for free ???

#) There are both a command-line makefile (no GUI required) and a makefile for
the IDE (for convenience). And in VC7 the project files are simply text that you
can edit and even automake if you want. What would be the problem to have them ?

#) Are there binary available of GLib under Win32 ? And if not, why not ?
Comment 7 Hans Breuer 2004-04-30 15:02:52 UTC
1#) my main point was that I fear it won't work reliable with static libs - and
there already is a bunch of error reports here which refernces GTK versions
which probably had only build failures :)

2#) definitely - but will the users notice ?

3#) Nope. I just like to use native tools which I can handle and am used to. And
I definitely have no problem to buy good software. Also if using free software
free as in speech is prefered ;-)

#) Having two additional 'build systems' to maintain does double the amount of
maintenance work, doesn't it ?

#) Lack on free time and resources I guess - if you meant the 2.4 version. The
older versions are available at the usual place
http://www.gimp.org/~tml/gimp/win32/downloads.html
Comment 8 Steve Lhomme 2004-04-30 20:14:59 UTC
#1) Mmm, I really don't see how the same code put inside or outside a .lib may
make such a difference ! But anyway, using the free tools, there's no other way
and IMO that should be the "preferred" way for the time being.

#2) Notice what ? That the names are different ? BTW, my goal is to make
GSTreamer work under Windows, with the free tools from Microsoft. I'm almost
there now (some changes still pending here and there). But not make the whole
Gnome stuff working this way. So in this case it doesn't matter if the binaries
are not the same. The idea is to have code as native and Windows friendly as
possible.

#4) I can take care of the maintenance of making GStreamer work the way we
intend it (explained above). I will take care of that for GStreamer, and GLib is
also needed so it's part of what I want to have working as much as possible...
There are many projects pending to use this combination, so it's unlikely to get
dead/abandonned soon.
Comment 9 Hans Breuer 2004-05-01 10:56:00 UTC
1#) here is one of the "explained elsewhere"
http://mail.gnome.org/archives/dia-list/2003-March/msg00141.html
Another problem when mixing runtimes are unmatched allocator/deallocator 
pairs say: 
g_new() calling into your statically linked c-runtime and g_free coming from a module
linked against msvcrt.dll. If you still think it could not "make such a differnce!"
lets stop this for now - but try to remember when you get strange memory access
errors or harmless stuff like gtk not using your gtkrc anymore ;-)

2#) Yepp. Do you think GStreamer will be used without a user interface ? If not -
do you plan to maintain your own double makefiles for pango/atk/gtk as well ? 
If not : goto 1#) for problems arising ...

BTW: what do you think is so terribly wrong with the current build system for msvc
(beside using nmake) that you want to add two new ones ?
One thing appears to be using nmake - cause M$ isn't giving it away for free? If I
find the time and a natively ported version of gmake - I'll give it a try. Shouldn't
be too hard for it to work better than nmake ...
Comment 10 Steve Lhomme 2004-05-01 11:37:27 UTC
#1) I am aware of the problem. That's why our DLLs are not compatible. Using the
makefile it's not possible to have them compatible with yours (does that mean
they should NOT exist ?), but using the IDE it's possible.

#2) GStreamer might be used with a UI someday under Windows. But right now it
all depends on my patches to be build on Windows (which have already been added
to CVS). It can also be used without a UI for conversion, capture, etc. And the
project we're going to do will not use GTK+ but wxWindows.

#3) There is nothing wrong in the existing system if it works for you. But you
can't force everyone to use your tools the way you do it. Especially if other
solutions exist (which I personally find more elegant)... GLib can be used out
of the whole Gtk/Gnome/GStreamer system. IMO it make sense to make available to
larger audience that might not use it the way YOU do it. AFAIK my
changes/additions don't break what you're using... If you don't want this to
happen I will make it available elsewhere for the people I work with.

#4) GNU make have been available for years for Win32. The version I use comes
from http://www.mingw.org/ (version 3.80).

So in the end you want to commit nothing of what I did ? Even the fixes in the
source files ?
Comment 11 Steve Lhomme 2004-05-01 14:47:18 UTC
Created attachment 27266 [details] [review]
Source-only fixes

Minor changes in the source that should not hurt anyone and make my life easier
:D
Comment 12 Steve Lhomme 2004-05-01 15:33:05 UTC
Created attachment 27267 [details] [review]
Same patch but working with nmake and commercial VC7

The same build process you use, but working with VS.Net 2003.

BTW, dirent is not built automatically.
Comment 13 Tor Lillqvist 2004-05-01 18:49:33 UTC
While working on that code, it probably would be better to use 
InterlockedCompareExchangePointer() instead of InterlockedCompareExchange(), 
and get get support for Win64 automatically (although there presumably are 
dozens of other places where changes will be needed for Win64).

I don't understand why you want to make the g_thread_priority_map visible, and 
that would be an API change on all platforms.

No need to include <glib.h> in gmodule-win32.c. gmodule-win32.c isn't compiled 
by itself, it is included in gmodule.c, which already includes glib.h 
(indirectly through gmodule.h). (Read the Makefile.am files to find out what 
source files are compiled.)
Comment 14 Tor Lillqvist 2004-05-02 05:29:42 UTC
One more note about InterlockedCompareExchangePointer: If you compile with gcc 
(as I do for my public distribution of glib), the assembly-language 
implementations of the g_atomic functions are what will be used. (See the 
G_ATOMIC_I486 branch of the ifdefs.)
Comment 15 Steve Lhomme 2004-05-02 09:23:43 UTC
Created attachment 27290 [details] [review]
Same patch with simplications from Tor

I also added a few things to make the compilation/cleaning smoother. Also would
it be possible to compile dirent automatically ? Maybe it's not possible if
it's part of the whole Gnome build system.
Comment 16 Steve Lhomme 2004-05-02 09:37:24 UTC
Created attachment 27294 [details] [review]
Same patch but reducing the size of the .dll/.exe produced
Comment 17 Tor Lillqvist 2006-05-09 09:57:08 UTC
The InterlockedCompare* stuff has been fixed now (bug #155884). GLib also now includes project files for Visual Studio 8. I don't think it's relevant to keep this bug open any longer. If you want to submit project files for Visual Studio 7 as well, open a new bug.