Re: glib compilation problem on windows



Do you intend to compile GLib for Cygwin or for Win32? 

I'm tryng to compile it for win32. I found a link to this package on :
http://www.gimp.org/~tml/gimp/win32/downloads.html
so I supposed that it was already configured for it.

(he is talking about my "snapshot" GLib source distribution
2.2.3-20040116, which I did to satisfy the LGPL, to go with my
corresponding snapshot binary GLib distribution.)

No, like the official source distributions of GLib, it isn't "already
configured" for anything. (The only difference from the official GLib
2.2.3 tarball is that some source files are a bit fresher.) 

You had to run the configure script, which produced the actual
Makefiles.

Do I need to edit all the makefiles to add the -mno-cygwin flag ?

No, you supply it in the CC environment variable to the configure
script.

CC='gcc -mno-cygwin' ./configure ...

 > I have use the --enable-static option with configure.

Why?

I want to build standalone win32 application like gimp, xchat, ...

By standalone, do you mean "not depending on any nonsystem DLLs"? That
is a futile attempt...

And talking about a "standalone GIMP" sounds a bit odd. With just the
GIMP .exe file you won't be able to do much... No plug-ins, no
brushes, no help files...

Ditto for GTK. Even if gtk and gdk were static libraries, you would
still have the message catalogs as separate files.

Even if you just want to avoid nonsystem DLLs, do you really want to
bloat not only the GIMP executable, but also every GIMP plug-in
executable with the glib, gmodule, gobject, gtk-win32, gdk-win32,
gdk-pixbuf, pango, pangowin32, Pango's shaper modules, atk, etc
libraries?

And I hope you are not forgetting libiconv, gettext-runtime,
FreeType2, fontconfig, expat, libtiff, libjpeg, libpng, zlib etc. All
these are available as prebuilt DLLs, usually not as static libraries,
so you would have to build them yourself.

Building GLib and GTK statically means that they can't any longer
deduce their installation location automatically at run-time, but must
either be installed in a fixed location (how can you know what drive
letter and/or path the end-user prefers?), or you must add some other
mechanism (Registry? Environment variables?) so that they find their
message catalogs, configuration files, etc.

The problem is that the programs works under cygwin but 
can't find the libgtk-win32-2.0-0.dll for example under
win32. Building a static binary will probably prevent this error

It's a very hard solution to a trivial problem. Surely it is much
easier just to make sure an executable will find its DLLs. What's
wrong with setting PATH? (You could even set it in a .bat file that is
used to start the executable, instead of globally.)

--tml





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]