Re: GLib and 64-bit Windows




 > I think I have made some progress...  at least the following libraries
 > have been built:

 > build/win32/dirent/dirent.lib
 > glib/gnulib/gnulib.lib

(These are just auxiliary libraries that are linked in the glib DLL.)
Right, but are nonetheless needed for the rest of glib. :-D

 > glib/glib-2.0.lib
 > gmodule/gmodule-2.0.lib
 > gobject/gobject-2.0.lib
 > gthread/gthread-2.0.lib

Hopefully these are just import libraries, and you got DLLs, too?

Apologies for forgetting that...

./glib/libglib-2.0-0.dll
./gmodule/libgmodule-2.0-0.dll
./gobject/libgobject-2.0-0.dll
./gthread/libgthread-2.0-0.dll

BTW, did you build the external libraries GLib depends on,
gettext-runtime (usually with an import library called "intl.lib") and
libiconv ("iconv.lib"), too, or did you find them somewhere prebuilt
for Win64?

I built these from scratch as well. They required very minor changes, if I remember correctly at this point.

 > glib/glib-2.12s.lib
 > object/gobject-2.12s.lib

These are static libraries. When building GLib for Win32 with gcc no
static libraries are produced, but the MSVC makefiles build such, too,
for some reason.
Unfortunately, our particular use of glib requires static libraries for everything (we static link on all the platforms our software is shipped on, to minimize runtime issues). I asked this on the list at some point in the past, and I think these are static libraries are (were?) for some type of bootstrapping during the build. I had to hack up the 2.8.6 build to get static libraries out of it.

 > Is running each of the test executables in the tests directory and
 > getting a 0 exit code for each a reasonable sanity check that everything
 > compiled correctly and is working?

Good!

The tests don't necessarily test everything, but this does indeed
sound promising.
Well, I didn't say that I *did* run them and get good outputs, I just wanted to make sure that was what the expected behavior was. :-) However, I have run the majority of them. Unfortunately there are a few that require inputs and I am clueless as to what they need to run. Most have passed, but spawn-test seems to freak out on me. I am checking to see if I can figure that out.

There are whole piles of warnings about signed/unsigned comparisons and type size issues:

warning C4311: 'type cast' : pointer truncation from 'gpointer' to 'long'
warning C4018: '<' : signed/unsigned mismatch
warning C4267: 'function' : conversion from 'size_t' to 'gssize', possible loss of data
warning C4090: 'initializing' : different 'const' qualifiers

I'm not sure which warnings are ignorable, and which are not. Personally, I'm quite pedantic about my own code, and like to fix everything, but I know that's not always feasible.

 Are you then going to proceed to build atk, Pango and GTK+?
Unfortunately, my company only uses glib as a platform compatibility library. We don't have any use for atk, Pango, or GTK+ in our product. We use a few tools later on that rely on glib, but none of the fancy libraries.



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