Re: GTK+ on windows

[Tor Lillqvist <tml iki fi>]

> 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