2009/10/13 Dov Grobgeld <dov.grobgeld@xxxxxxxxx>: > I have created several cross-platform gtk programs, and while it took a > while to get right the first time, my development is now so trustworthy that > I can do all my development under Linux and then once it works, just > generate a windows installer and I know that it will just work. I agree, after struggling with gcc on Windows, MSVC and even cmake and jam, I now cross-compile from Linux and it works wonderfully. This solution has the following nice properties: *) I have not only a single, cross-platform source tree, I also have a single build system to maintain. *) It's very scriptable (my bash is much better than my VBA of whatever the Windows equivalent is). For example, I have a simple script that does a nightly build from SVN, updates a website with a fresh Windows binary, and sends me a mail if there were any problems. *) It's much faster than mingw on Windows, though I guess that's not saying much, heh. I don't build gtk+ myself, I use Tor's zips plus a few other packages I've had to build myself. I can update parts of the stack by just dropping an updated zip into the tree, it's about as nice as it could be without a proper package manager. > microsoft like you can make it use the intel compiler?) In any case, as gtk > is a pure c-program, there are no ABI differences between the visual > compiler and gcc. So why can't you just use the standard gtk distribution > together with the studio compiler? My understanding is that there are differences in the C runtime. mingw links against msvcrt.dll (the runtime from VC6) since this is the one that's guaranteed to be on almost all Windows machines, so you don't need to bundle a C runtime, so there's no problem with rights. Almost all free DLLs are built like this, I believe. Current VS links against msvcrt80.dll (is that right? can't remember) which is not present on all machines and needs to be bundled in your installer, which is a little dubious. Even if you take the IP risk and bundle it, that's not enough, you really need to run an installer for it as well and make some registry changes before i18n will work in the runtime. Erm, I think. The upshot is that VS projects can't link against GTK DLLs, unless you fiddle with the VS link stuff to link against msvcrt.dll instead of the more recent one, which is quite difficult to do, I think. Or this blog suggests that it is anyway: http://kobyk.wordpress.com/2007/07/20/dynamically-linking-with-msvcrtdll-using-visual-c-2005/ I'm not a Windows person at all though, I've probably got most of that wrong :( Friends who do serious Windows application development simply statically link everything to avoid all this pain. John _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
