GTK+ on windows

[Ted Bullock-2]

In the background of writing some software on top of GTK+ I have
started working on making my application build on windows rather than
just my opensuse-factory desktop.

Looking at the the information on gtk.org I thought to myself, maybe I
can just create a visual studio project file for the entirety of GTK
and have my little application sitting along side all the other
components.  This way, I can ensure binary compatibility and can take
advantage of all the dependency management and debugging facilities
included with visual studio and just maybe flowers will spring up on
the desert and all that.

I have had a reasonable amount of success, along with a reasonable
amount of pain.  Currently about 60% of the dependencies are building
and linking.

However this has got me thinking about what the nature of the
portability problem is here.  Lots of projects have released Windows
GTK binaries at one point or another, but I wouldn't trust that there
is a great deal of ABI compatibility between them.  Currently each
project maintains it's own build system on Windows some of which are
extremely painful and a massive wall to participation.  And all I am
doing with the work on my project is setting up "yet another gtk
distribution".

The amount of fragmentation around GTK on the windows platform is
pretty significant and building a GTK application for windows is not
for the faint of heart (Take a look at the build instructions for
gedit)

Although mingw produces working results, the process is complicated.
Statements like the one on gtk.org about the gnu compiler being an
appropriate toolchain are ill conceived not because there is anything
wrong with the toolchain itself, but rather because it's not native to
the platform.

In response to this and specifically to scratch my own itch I am
starting a new project called Nokomis (Ojibwa spirit who rebuilt the
world from a grain of sand).  Which, while not a fork of GTK will be a
Windows specific compilation of GTK using msbuild very much in the
same way that xenocara implements X for OpenBSD.

Nokomis will provide missing functionality such as asprintf, strlcpy,
strlcat and attempt to track upstream GTK releases.  The targeted
system compiler will initially be the visual C compiler built into the
upcoming Visual Studio 2010 (currently in beta) although any compiler
which can be tied into msbuild will be acceptable.

Basically I want to make GTK a first class citizen on Windows

--
Ted Bullock <tbullock@...>
_______________________________________________
gtk-list mailing list
gtk-list@...
http://mail.gnome.org/mailman/listinfo/gtk-list

[Dov Grobgeld-2]

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 am using mingw for all my windows gtk work, and usually I'm doing the windows generation through cross compilation. My build environment is scons with a SConstruct file that has a couple of if's in the beginning to resolve the differences between the different environments.

Trying to say that using mingw instead of MSVC makes the result less native is as absurd as saying that using the Intel compiler would make it less native. Of course there are people who for whatever reason prefer the Studio IDE, and I respect that. (Can you configure Studio to use gcc instead of 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? If it doesn't work, I think it would make sense to enter whatever #ifdef's into the headers to support the microsoft compiler. Having two sets of "official" gtk windows environment sounds quite messy.

Regarding supplying missing asprintf() etc support, isn't that the job of glib? Are there reallly dependencies for glib that are not correctly supplied?

One more thing. After a long time of DLL-hell it has been settled that each application provides an entire copy of all the gtk runtime environment. This solves the earlier problem of competing gtk environments, and one application causing others not to work. Please don't try to generate an "official" gtk version that everybody should settle on. It hasn't worked in the past. The overhead of the entire gtk distribution isn't more than a around 12M which is negligible with todays hard disks. The only downside with this process is that you have to do theming separately for each application. But if you use the wimp theme, you inherit the windows theme in any case.

Regards,
Dov

On Tue, Oct 13, 2009 at 15:16, Ted Bullock <tbullock@...> wrote:

In the background of writing some software on top of GTK+ I have
started working on making my application build on windows rather than
just my opensuse-factory desktop.

Looking at the the information on gtk.org I thought to myself, maybe I
can just create a visual studio project file for the entirety of GTK
and have my little application sitting along side all the other
components.  This way, I can ensure binary compatibility and can take
advantage of all the dependency management and debugging facilities
included with visual studio and just maybe flowers will spring up on
the desert and all that.

I have had a reasonable amount of success, along with a reasonable
amount of pain.  Currently about 60% of the dependencies are building
and linking.

However this has got me thinking about what the nature of the
portability problem is here.  Lots of projects have released Windows
GTK binaries at one point or another, but I wouldn't trust that there
is a great deal of ABI compatibility between them.  Currently each
project maintains it's own build system on Windows some of which are
extremely painful and a massive wall to participation.  And all I am
doing with the work on my project is setting up "yet another gtk
distribution".

The amount of fragmentation around GTK on the windows platform is
pretty significant and building a GTK application for windows is not
for the faint of heart (Take a look at the build instructions for
gedit)

Although mingw produces working results, the process is complicated.
Statements like the one on gtk.org about the gnu compiler being an
appropriate toolchain are ill conceived not because there is anything
wrong with the toolchain itself, but rather because it's not native to
the platform.

In response to this and specifically to scratch my own itch I am
starting a new project called Nokomis (Ojibwa spirit who rebuilt the
world from a grain of sand).  Which, while not a fork of GTK will be a
Windows specific compilation of GTK using msbuild very much in the
same way that xenocara implements X for OpenBSD.

Nokomis will provide missing functionality such as asprintf, strlcpy,
strlcat and attempt to track upstream GTK releases.  The targeted
system compiler will initially be the visual C compiler built into the
upcoming Visual Studio 2010 (currently in beta) although any compiler
which can be tied into msbuild will be acceptable.

Basically I want to make GTK a first class citizen on Windows

--
Ted Bullock <tbullock@...>
_______________________________________________
gtk-list mailing list
gtk-list@...
http://mail.gnome.org/mailman/listinfo/gtk-list

_______________________________________________
gtk-list mailing list
gtk-list@...
http://mail.gnome.org/mailman/listinfo/gtk-list

[Vivien Malerba]

2009/10/13 Dov Grobgeld <dov.grobgeld@...>:

> 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 am using
> mingw for all my windows gtk work, and usually I'm doing the windows
> generation through cross compilation. My build environment is scons with a
> SConstruct file that has a couple of if's in the beginning to resolve the
> differences between the different environments.
>
> Trying to say that using mingw instead of MSVC makes the result less native
> is as absurd as saying that using the Intel compiler would make it less
> native. Of course there are people who for whatever reason prefer the Studio
> IDE, and I respect that. (Can you configure Studio to use gcc instead of
> 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

I'm making a library using a cross compilation environment and it
works fine, except when one tries to use that library I've compiled
using mingw from the visual studio IDE because then the whole
application ends up being linked to several msvcrt*.dll files which
can't share anything, and crashes if anything is shared (like for
example stdout).

So for libraries, the environment (and compiler) used to generate the
DLL is important for the person using that DLL and from what I know
Windows developpers most of the time don't use GCC.

Anyway that's my small Windows experience.

Vivien
_______________________________________________
gtk-list mailing list
gtk-list@...
http://mail.gnome.org/mailman/listinfo/gtk-list

[David Nečas (Yeti)-2]

On Tue, Oct 13, 2009 at 03:49:16PM +0200, Dov Grobgeld wrote:
> One more thing.

More or less agreeing with the previous points, except the main one:

> After a long time of DLL-hell it has been settled that each
> application provides an entire copy of all the gtk runtime environment.

But why on earth it needs to be *bundled* with the application?

Even though the application installs a private copy of Gtk+ why it needs
to do so on every update?

> This
> solves the earlier problem of competing gtk environments, and one
> application causing others not to work. Please don't try to generate an
> "official" gtk version that everybody should settle on. It hasn't worked in
> the past.

It has worked for me.  Not everyone wants to maintain a private Gtk+ MS
Windows distribution.

A Gtk+ distribution that could be installed privately for an application
but would be still separated from the application would be terrific.

There needs to be some mechanism to coordinate the installation
directory of the app and this plug-in Gtk+ distro, but supporting that
in the app is much less work than supporting entire Gtk+.

> The overhead of the entire gtk distribution isn't more than a
> around 12M which is negligible with todays hard disks.

I'm sorry, if my application has 1.5 MB then 12 MB is not negligible
*no matter how large the disks are*.

Yeti

_______________________________________________
gtk-list mailing list
gtk-list@...
http://mail.gnome.org/mailman/listinfo/gtk-list

[jcupitt]

2009/10/13 Dov Grobgeld <dov.grobgeld@...>:
> 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@...
http://mail.gnome.org/mailman/listinfo/gtk-list

[Ted Bullock-2]

A couple points

Dov:

A lot of what you are talking about relates to distribution rather
than build.  Applications can distribute gtk however they want, I am
talking about how one goes about building their application.

The problem with the build system is that it is really hard to use it
from windows.  There are tons of windows developers out there who
might want to make GTK applications and maybe they don't because
setting up a build environment is a massive wall.  Linking to the
package provided by Tor would be fine except it uses a different c
runtime and thus doesn't work.

One shouldn't have to configure the universe and learn entirely new
build systems to use GTK

David:

Yes, you pretty much captured my reasoning.

John:

I am talking about removing the struggle for developers using msvc (or
the intel compile for that matter), while it's cool that you have a
system that works for you I would be willing to bet it took a long
time to get set up correctly.

As to scriptability, the msbuild stuff (available for c projects from
msvc 10 onwards) is pretty slick.

And yes I can relate to why someone would statically link the whole of
gtk into their application.

To sum up.

To be honest I am not a windows person either, I just write write
software for the oil and gas industry and about 0% of them use linux,
bsd or anything like it.  I want to be able to squeeze open source
software into that environment.

So how this is going to work is similar to how openbsd works with
xenocara. Pick and choose the components which work together, send
patches upstream to those that don't.  Common global include directory
for public dependancy headers.  Each dependancy with its own msbuild
project.

By the way, here is the kb article regarding the c runtime redistribution:
http://support.microsoft.com/kb/326922

I am putting together a little spec explain how it will work in detail
which should be available soon enough.

Anyways, I want to re-iterate that I am scratching my own itch, if you
find that you aren't itchy in the same way as me that's cool.
_______________________________________________
gtk-list mailing list
gtk-list@...
http://mail.gnome.org/mailman/listinfo/gtk-list

[Ted Bullock-2]

Here is a little update on my project to get gtk building in the
visual studio tool chain.

glib.dll

* Successfully compiles with both intel c and msvc

* Only one extremely minor code change to glib for it to build
(_snprintf rather than snprintf)

* GNU gettext is hopeless and unportable in it's current state, using
a custom stub I wrote myself because the one from Tor looks way too
cluttered for my brain to wrap around it.

*Horrendous number of 64bit->32bit data loss compiler warnings since
things like size_t return types are routinely ignored, as well as
storing pointer arithmetic results into 32bit int.

Some size comparisons:
mingw glib (889 KB)
msvc glib (304 KB)
intel c glib (192KB)

As one would expect the intel compiler is considerably better than microsoft.

The mingw result is a bit predictable considering it has to pull in
half the universe to function outside of its natural habitat.

Anyways, I wanted to post the above results as a proof of concept to
demonstrate that maybe this just might be the right way to go.

Things like gio, gthread etc haven't been started yet, but I would
expect the same drop in binary size clear across the board, mingw
produces a gtk.dll over 3mb so lets cross our fingers.

Looking forward in time, dependencies like libjpeg, libtiff, libpng
can probably be replaced with native gdi+ functionality to further
reduce the complexity of the stack.
http://msdn.microsoft.com/en-us/library/ms536393(VS.85).aspx

Also, #include "config.h" should be wrapped in HAVE_CONFIG_H
everywhere....  What a pain in the ass.

I chose to use the latest pcre rather than whatever comes with glib.
It seemed appropriate.

Lastly, I'll throw up a google code project for the whole shebang if
there is interest.  I could certainly use some help.

--
Ted Bullock <tbullock@...>
_______________________________________________
gtk-list mailing list
gtk-list@...
http://mail.gnome.org/mailman/listinfo/gtk-list

[Tor Lillqvist]

> * GNU gettext is hopeless and unportable in it's current state,

Well, "unportable" is perhaps a bit pessimistic, as it is possible to
build it both for 32-bit and 64-bit Windows and both builds seem to
work as far as I see. But it certainly is a pain, indeed. One can only
hope that if a 0.18 (or 1.0 even) version some day appears, the
codebase will have been significantly cleaned up.

> Some size comparisons:
> mingw glib (889 KB)
> msvc glib (304 KB)
> intel c glib (192KB)

Could you please explain exactly how you end up with these numbers?
Size of what? Size of the DLL? Sum of sizes of the "loadable"
segments? Or what? What glib version? The "official" (mingw-built)
glib DLL or a self-built one for mingw, too? What kind of optimization
options?

I am not doubting that Intel's compiler is better (for some value of
"good") than Microsoft's or gcc. But still the above numbers are
rather amazing. Strong claims need strong proofs;)

> The mingw result is a bit predictable considering it has to pull in
> half the universe to function outside of its natural habitat.

I don't immediately see what huge amounts of code a mingw-built glib
DLL would need to "pull in" that a MSVC- or Intel-built one wouldn't?
Certainly not enough to explain the huge differences above.

> Looking forward in time, dependencies like libjpeg, libtiff, libpng
> can probably be replaced with native gdi+ functionality to further
> reduce the complexity of the stack.

That possibility is already present. (And after bug #552678 was fixed
recently, it should even work. Fix has been committed to master and
gtk-2-18.)

> Also, #include "config.h" should be wrapped in HAVE_CONFIG_H
> everywhere....

No it should not. It simply is not supposed to be meaningful or
possible to build glib or gtk+ without a config.h, so it is pointless
to use HAVE_CONFIG_H, they just clutter the code.

> I chose to use the latest pcre rather than whatever comes with glib.
> It seemed appropriate.

Please file a bug with a patch then?

> Lastly, I'll throw up a google code project for the whole shebang if
> there is interest.

It would be more interesting to get separate patches for specific
issues into bugzilla than to have to look at a separate forked code
repository...

> I could certainly use some help.

So could we, for actual Windows-specific bugs and misfunctionality in
the code. Hopefully once you have your build system working nicely,
you will be able to help with that? Getting project files for building
the gtk+ stack with Visual Studio will certainly be nice! Hopefully
you will be interested in upstreaming such.

--tml
_______________________________________________
gtk-list mailing list
gtk-list@...
http://mail.gnome.org/mailman/listinfo/gtk-list

[Ted Bullock-2]

On Fri, Oct 16, 2009 at 6:43 AM, Tor Lillqvist <tml@...> wrote:
>> * GNU gettext is hopeless and unportable in it's current state,
>
I should have added that I am very sleepy having not gone to bed last
night so perhaps the above note was just a bit of weariness creeping
in.
--
Ted Bullock <tbullock@...>
_______________________________________________
gtk-list mailing list
gtk-list@...
http://mail.gnome.org/mailman/listinfo/gtk-list

[Ted Bullock-2]

On Fri, Oct 16, 2009 at 6:43 AM, Tor Lillqvist <tml@...> wrote:

>> Some size comparisons:
>> mingw glib (889 KB)
>> msvc glib (304 KB)
>> intel c glib (192KB)
>
> Could you please explain exactly how you end up with these numbers?
> Size of what? Size of the DLL? Sum of sizes of the "loadable"
> segments? Or what? What glib version? The "official" (mingw-built)
> glib DLL or a self-built one for mingw, too? What kind of optimization
> options?
>

These are the sizes of the working binary dll not include extras like
gio.dll and related libraries.  Simply the glib.dll.  The glib came
out of a build I did a ways back using pretty much the standard build
process (configure make and make install) on the way to building
gedit.  I didn't change anything here so it was probably O2.  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?

On the Visual Studio platform using O2 optimization level
glib.dll from my project from the Microsoft compiler is 304 KB
glib.dll from my project from the Intel compiler is 192 KB

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.

>> Looking forward in time, dependencies like libjpeg, libtiff, libpng
>> can probably be replaced with native gdi+ functionality to further
>> reduce the complexity of the stack.
>
> That possibility is already present. (And after bug #552678 was fixed
> recently, it should even work. Fix has been committed to master and
> gtk-2-18.)
>

Very cool, so will I need to build these or not?  Does cairo still require them?


>> Also, #include "config.h" should be wrapped in HAVE_CONFIG_H
>> everywhere....
>
> No it should not. It simply is not supposed to be meaningful or
> possible to build glib or gtk+ without a config.h, so it is pointless
> to use HAVE_CONFIG_H, they just clutter the code.
>

I thought that was what glibconfig.h would be used for.  If not, why
have two config files?


>> I chose to use the latest pcre rather than whatever comes with glib.
>> It seemed appropriate.
>
> Please file a bug with a patch then?

Why is this included with the library anyways, why not just have it as
an external dependency and delete it from glib?

>
>> Lastly, I'll throw up a google code project for the whole shebang if
>> there is interest.
>
> It would be more interesting to get separate patches for specific
> issues into bugzilla than to have to look at a separate forked code
> repository....

Hmm, I see what you mean.  Here is my consideration though, the
directory layout of glib is not terribly conducive to being built
inside of visual studio.  Because there are a large number of
dependences sharing header files it became easier to just pull the
necessary public headers out of the distributed layout and drop them
into a single include directory located at $(SolutionDir)include

This is this way because visual studio does not export public include
directories from dependencies (although it does export linker
dependencies)

This has some ramifications of course since it becomes harder to
create patches against upstream versions (need to do it basically on a
file-by-file basis and glue the results afterwards).  But it makes the
build and dependency management process a billion times easier.  I
have tried to do it a couple times against a packages original
directory layout and had major complexity issues.

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
and bundles a windows compliant config.h.

The zip would contain only those files necessary in a windows build in
a predictable directory layout.

I currently have
/include
/source/applications/$ProjectName (If project is an application)
/source/library/$ProjectName (If project is a library)
/project/$ProjectName/$ProjectName.vcproj

You'll note that I didn't use names like src or lib or bin because I
want to emphasize that this is a departure from the FHS world.  Such a
zip would fit seamlessly into my build environment.

Tracking upstream becomes it's own task, but this is likely going to
remain that way anyways so perhaps a bit of deliberateness is
appropriate.  Having a common distribution of the build environment
makes it profoundly easier to use it.  Just look at how QT is
distributed and how it supports visual studio.

>> I could certainly use some help.
> So could we, for actual Windows-specific bugs and misfunctionality in
> the code.
Yes, I concur.  As a side note, who generally works on the win32 stuff
other than yourself?

> Hopefully once you have your build system working nicely,
> you will be able to help with that? Getting project files for building
> the gtk+ stack with Visual Studio will certainly be nice! Hopefully
> you will be interested in upstreaming such.

I will certainly make everything I do available to upstream

--
Ted Bullock <tbullock@...>
_______________________________________________
gtk-list mailing list
gtk-list@...
http://mail.gnome.org/mailman/listinfo/gtk-list

[David Nečas (Yeti)-2]

On Sat, Oct 17, 2009 at 02:59:37AM -0600, Ted Bullock wrote:

> >> Also, #include "config.h" should be wrapped in HAVE_CONFIG_H
> >> everywhere....
> >
> > No it should not. It simply is not supposed to be meaningful or
> > possible to build glib or gtk+ without a config.h, so it is pointless
> > to use HAVE_CONFIG_H, they just clutter the code.
> >
>
> I thought that was what glibconfig.h would be used for.  If not, why
> have two config files?

Funny you are trying to make our own Gtk+ distro without knowing what
config.h and glibconfig.h are for...

config.h contains system information/configuration used to build the
package (glib here).  It is a private header.  Some programs can compile
without config.h even though they have configure but these are either
simple (wrt system dependencies) or were very carefully written to have
some `reasonable' default for anything system-dependent.  Glib
definitely isn't the former and the latter is not always possible.  You
are expected to create a static config.h for a system where automatic
configuration is not possible[*].

glibconfig.h is a public header and it contains information about
configuration of glib on that system that is necessary to build programs
using glib.  It is placed in lib/lib64/lib32 instead of include because
the configuration can (and do) differ between 32bit and 64bit versions
(for instance) while include is, in theory, shareable even among
different systems.  You are expected to create a static config.h for a
system where automatic configuration is not possible[*].

Some information might be present in both headers (typically not in the
same form though), anyway, you cannot have only glibconfg.h and make
everything public because that would expose private stuff that should
not be exposed, neither you can have only the private config.h because
then programs using glib couldn't get any system dependent information
about glib.

[*] glib provides these static headers for win32.

Yeti

_______________________________________________
gtk-list mailing list
gtk-list@...
http://mail.gnome.org/mailman/listinfo/gtk-list

[Tor Lillqvist]

> 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@...
http://mail.gnome.org/mailman/listinfo/gtk-list