> These are the sizes of the working binary dll OK, so this then includes also sections that have no impact at run-time size. Please use a tool like "size -A" or "link -dump -headers" to check the size of just those sections that actually are used by the code at run-time. > Looking at your version though from gtk.org glib-2.0.0.dll is over 1 Mb, how > are you building that? Are the debugging symbols in there? Apparently gcc is pretty insistent to always include a degree of symbolic information. For my 2.22.2-1 GLib build, I get: c:/devel/dist/win32/glib-2.22.2-1/bin/libglib-2.0-0.dll : section size addr .text 552848 1750863872 .data 2192 1751416832 .rdata 288960 1751420928 .bss 5504 1751711744 .edata 37553 1751719936 .idata 5344 1751760896 .rsrc 1012 1751769088 .reloc 25124 1751773184 .debug_aranges 192 1751801856 .debug_pubnames 215 1751805952 .debug_info 6368 1751810048 .debug_abbrev 1779 1751818240 .debug_line 1364 1751822336 .debug_frame 276 1751826432 .debug_loc 3255 1751830528 .debug_ranges 416 1751834624 Total 932402 and this is built without -g, but still there are some .debug_* (dwarf2 symbolic information) there. If I recall correctly, there is additionally the "COFF symbol table" (as pointed to by the PointerToSymbolTable and sized by the NumberOfSymgols fileds in the IMAGE_FILE_HEADER struct; use some PE executable file viewer or dumper to check) and it doesn't even show up in a "size -A" output, but is still present especially in executables produced by the GNU tool-chain. That probably explains why size says "Total 932402" but the size of the DLL is 1109237 bytes. As a comparison, my "working" build of the GLib stable (2.22) branch has sizes: c:/devel/target/stable/bin/libglib-2.0-0.dll : section size addr .text 592952 1750863872 .data 4784 1751457792 .rdata 287712 1751465984 .bss 5568 1751756800 .edata 37553 1751764992 .idata 5520 1751805952 .rsrc 1012 1751814144 .reloc 26556 1751818240 .debug_aranges 2848 1751846912 .debug_pubnames 68415 1751851008 .debug_info 677813 1751920640 .debug_abbrev 47065 1752600576 .debug_line 84364 1752649728 .debug_frame 56940 1752735744 .debug_str 9036 1752793088 .debug_loc 86723 1752805376 .debug_ranges 4272 1752895488 Total 1999133 This is built with -g, and as you see the .debug_* sections are significantly larger. The code (.text) section is a bit larger, too, because no optimization was used. > Note that with the intel and microsoft toolchain, the debug symbols > are stored externally in a separate database which can be linked in at > run time or discarded. I doubt the .pdb files are ever "linked in" (mapped into memory) except by a debugger. > Very cool, so will I need to build these or not? Does cairo still require them? Cairo requires libpng only if you configure it to provide its optional PNG-related API. > I thought that was what glibconfig.h would be used for. If not, why > have two config files? You already got a reply for this. > Why is this [pcre] included with the library anyways, why not just have it as > an external dependency and delete it from glib? On systems where there *is* a system pcre and functioning package management (i.e., sensible UNIX and Linux systems), the system pcre *is* normally used. Check the --with-pcre option in configure.in. > Here is my consideration though, the > directory layout of glib is not terribly conducive to being built > inside of visual studio. [...] Hmm, I can't really say I could follow the reasoning here. Will have to read it more closely later. Although I guess it could be that the concept of what "make install" does is foreign here? And the concept of a "build tree" being a very different thing than an "install target"? What is the normal way to build some library A intended for distribution to others in Visual Studio, if one then *also* happens to want to use (the public API of) that library A in some other library or application B? Is it normal to make the project files of that other library or app B refer directly to the *build* tree of library A? I.e., to require that somebody can not build B without having the sources of A also present (and maybe even building A)? > That said maybe I (or someone else...hint hint) could write a "make > dist-windows" target into the autotools stuff which creates a zip file Nah, the source tarballs should be enough. It shouldn't be *that* hard to unpack a .tar.gz or .tar.bz2 tarball on Windows. And I don't really think it makes sense to structure the source files differently for Windows builds. > and bundles a windows compliant config.h. There *is* one such in both the GLib and GTK+ source tarballs, config.h.win32. They are manually maintained and I must admin I am not sure how well maintained the GTK+ one is, but the one in GLib should be usable. (There is also a prebuilt glibconfig.h for Windows, glibconfig.h.win32.) > Such a zip would fit seamlessly into my build environment. But would it fit into anybody else's? There are also other people working on building GLib and related stuff with Visual Studio, and they presumably have different conventions... If you think you are the only person doing what you do you are mistaken. One person "pierre" is actively present in the #win32 channel on IRC (irc.gimp.org) and works on PHP, and apparently GLib is used in some way by PHP stuff on Windows, I don't know the details myself, have never used PHP. And then there is Hans Breuer who is a long-time contributor to the GTK+ stack for Windows, as far as I know he also uses the Microsoft tool-chain, but nmake and not Visual Studio to do his builds. > Having a common distribution of the build environment > makes it profoundly easier to use it. Sure. as long as there indeed is just one "common" such... and the closer relation it has to upstream, the more likely it is that it won't bit-rot into obsolescence when new files are introduced into the source code etc. > Just look at how QT is > distributed and how it supports visual studio. I think there is a definite difference here in that QT is actively marketed also to Windows-based developers and the company behind it has a business interest in maintaining it and its build system for Windows, and it is also more clear that QT upstream has a natural authority to decide how it is built with a Microsoft tool-chain. (And because they have such an authority, there is little opposition.) (Just as in the GTK+ stack case, upstream has authority on how an auto* and GNUish tool-chain based build works.) Or am I mistaken? > As a side note, who generally works on the win32 stuff other than yourself? Check the git logs... > I will certainly make everything I do available to upstream Thanks. --tml _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
