Re: GTK+ on windows
- From: Tor Lillqvist <tml iki fi>
- To: Ted Bullock <tbullock comlore com>
- Cc: gtk-list gnome org
- Subject: Re: GTK+ on windows
- Date: Sat, 17 Oct 2009 21:24:29 +0300
> 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]