GNOME Bugzilla – Bug 328691
Microsoft Visual Studio 2005 compilation
Last modified: 2006-01-31 10:59:59 UTC
Hi, I found VS.2005 environment a very nice one and it seems to better support C99. Also it has a lot of good features, like profiling, boundary and security checks in the code. This could be usefull when you debug applications. In order to contribute some code to gstreamer I need to build it and be able to debug it right from VS.2005. For this I need to compile all the dependancies because there are crashes appeared when you try to mix msvcrt.dll and msvcr80.dll runtimes: xlib is compiling without any problems in VS.2005 because there exist VS project files, for glib I didn't find any VS.2005 project files and faced some problems compiling it from command line. So I created the required project files for VS.2005 and attached them to bug. Please include them to CVS, this will save a lot of time for the people like me that want to debug other applications that depends on glib right from VS.2005 Please note that I understand that you cannot distribute the build linked with msvcr80.dll because it is not a part of OS and this breaks GPL. I just asking to add VS project files.
Created attachment 58138 [details] VS.2005 project files the vs8 directory attached need to be added to build/win32 directory. If you think that it is not the right place please tell me I will move them to another location and modify project files acordingly.
As addition to this feature enhancement is it possible to remove G_GNUC extentions from generated files: glib.def gobject.def gthread.def gmodule.def. Here they are: G_GNUC_MALLOC G_GNUC_CONST G_GNUC_PRINTF(4,5) G_GNUC_NULL_TERMINATED G_GNUC_NORETURN This extentions doesn't compiled with Visual Studio.
Thanks. I think the glib.sln and *.vcproj files could be added to CVS, yes. Probably could be included in the source tarballs too. One thing I would strongly recommend, though, is that you use different names for your DLLs that are linked to msvcr80.dll. For instance glib-2.0-0-msvcr80.dll, if that isn't too verbose. Then there will be less chance of mixup with the official ones linked to msvcrt.dll. The import library could be glib-2.0-msvcr80.lib. As for the .def file, you need to generate it from the .symbols files in such a way that the G_GNUC_* stuff gets stripped. See Makefile.am. I guess there is no sed-like tool included with VS? Hmm, just prepend a file with #defines for the G_GNUC_* macros that make them expand to nothing, and pass to cl /E.
If I will use different names that will add some work to developers. For ex. gstreamer(or any other) project has VS6 project files. They are configured with glib-2.0.lib. In order to compile gstreamer in VS.2005 I just convert project files to VS.2005 (done automaticaly) and compile it successfully with glib-2.0-0.dll that is linked with msvcr80.dll. If I change the name the developers will need to change gstreamer project settings - and this is a pane. these project files are only for development - no one should distribute glib-msvcr80.dll and glib-msvcr80.lib and it is up to developer to check if the correct glib-2.0-0.dll is used. Depends and little attention should help here. I agree that simple user could easy mix two dlls and that will cause crash but these project files for developers. As for *.def files I will create a prebuild event to generate def files with echo EXPORTS > glib.def cl /EP -DG_GNUC_MALLOC -DG_GNUC_CONST -DG_GNUC_PRINTF -DG_GNUC_NULL_TERMINATED -DG_GNUC_NORETURN -DINCLUDE_VARIABLES -DG_OS_WIN32 -DINCLUDE_INTERNAL_SYMBOLS -DALL_FILES glib.symbols >> glib.def and attach updated project files. probably there is need to change makefile.msc.in files for adding defines for G_GNUC_* like above. Please comment the part about renaming.
Sorry the solution above regarding defining -DG_GNUC_MALLOC is not working. Is it possible to autogenerate *.def files on build machine were sed is present to strip these defines and include *.def files in src release like it is done for gmodule.def and gthread.def? Sorry for posting before checking.
OK, so maybe the import libraries should have the same name regardless of what C runtime the DLLs use. But I do think that the GLib DLLs that an user builds should , if at all possible, be made to have different name if they are fundamentally ABI incompatible with the official ones. Sure, I guess tarballs could well contain pre-generated .def files. Matthias, if you are reading this, do you see any problem with simply adding glib.def to the EXTRA_DIST in glib/Makefile.am? (And ditto for gobject.def)
Created attachment 58201 [details] Updated project files I postfix output dll files with -vs8 (libglib-2.0-0-vs8.dll). I didn't use -msvcr80 because in Debug I should postfix it -msvcr80d, a bit confusing.
Project files added to HEAD. Will be included in the next development branch release (2.9.x). Thanks!