GNOME Bugzilla – Bug 141485
GLib doesn't include makefiles for Microsoft tools
Last modified: 2011-02-18 16:13:57 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.
Created attachment 27227 [details] [review] This patch will allow compilation from both the IDE and the command-line
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?
#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 ?
> Should I submit a new patch with all said ? Maybe wait for some comment by Hans (and/or other interested parties) first.
#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
#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 ?
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
#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.
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 ...
#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 ?
Created attachment 27266 [details] [review] Source-only fixes Minor changes in the source that should not hurt anyone and make my life easier :D
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.
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.)
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.)
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.
Created attachment 27294 [details] [review] Same patch but reducing the size of the .dll/.exe produced
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.