Re: Glib-Windows Compilation Issues

[Jake Goulding <goulding vivisimo com>]

Hans:

Thank you for the helpful comments and pointers.

I took a second look at the ftruncate comment I made earlier. Indeed, 
you are correct, there is no other definition of  g_win32_ftruncate. I 
did get an error before I made my change, so I will have to go back and 
try to ascertain the real cause of it. As for the static libraries, I 
realize that the dynamic libraries are the supported mechanism, but 
static libraries are the method that this program was previously using 
(I believe I forgot to mention I am upgrading from glib 2.2.2 to 2.8.6) 
and I prefer to not change more than is needed.

I had a sneaking suspicion that the prefix was something added by the 
compiler, but I didn't have any real evidence to back up my thoughts. Do 
you have any tips as for the incomplete static libraries / which magic 
files I need? I realize that this is a bit outside of 'supported', but 
any help is appreciated!

Thanks again!

-jake


Hans Breuer wrote:
> On 17.03.2006 22:40, Jake Goulding wrote:
> > Hey all:
> >
> > I've had some trouble in compiling and subsequently using glib 
> > (2.8.6) on a Windows machine.
> >
> > I am building using nmake and the MSVC toolset. My procedure is such:
> >
> > unpack glib into a directory containing gettext and libiconv.
> > cd build/win32/dirent
> > nmake -f makefile.msc
> > cd ../../../
> > nmake -f makefile.msc
> >
> > Then the trouble starts... I have gotten it to compile, and my 
> > patches are included here. The very bottom describes my current trouble.
> >
> > ################################################################################## 
> >
> >
> > I had to make the following changes to work around differing level of 
> > indirection errors:
> >
> > diff -r --unified glib-2.8.6/glib/gatomic.c gmod/glib/gatomic.c
> > --- glib-2.8.6/glib/gatomic.c   2005-12-17 07:26:54.000000000 -0500
> > +++ gmod/glib/gatomic.c 2006-03-15 10:27:21.907293400 -0500
> > @@ -514,9 +514,9 @@
> >                                   gint32    oldval,
> >                                   gint32    newval)
> > {
> > -  return (guint32)InterlockedCompareExchange ((PVOID*)atomic,
> > -                                              (PVOID)newval,
> > -                                              (PVOID)oldval) == oldval;
> > +  return (guint32)InterlockedCompareExchange (atomic,
> > +                                              newval,
> > +                                              oldval) == oldval;
> > }
> >
> > gboolean
> > @@ -527,7 +527,7 @@
> > # if GLIB_SIZEOF_VOID_P != 4 /* no 32-bit system */
> > #  error "InterlockedCompareExchangePointer needed"
> > # else
> > -   return InterlockedCompareExchange (atomic, newval, oldval) == 
> > oldval;
> > +   return InterlockedCompareExchange ((volatile long *)atomic, 
> > (long)newval, (long)oldval) == (long)oldval;
> > # endif
> > }
> > #endif /* DEFINE_WITH_WIN32_INTERLOCKED */
> http://bugzilla.gnome.org/show_bug.cgi?id=155884
>
> > ################################################################################## 
> >
> >
> > I also had to remove support for g_win32_ftruncate, as mingw has it 
> > defined, and I later want to link glib against mingw-compiled code:
> Do you say there is a symbol in mingw outside of glib defined with the
> name g_win32_ftruncate ? I doubt this and you code does something 
> different.
> If only for mingw you do
> #define ftruncate g_win32_ftruncate
> you are just breaking GLibs ABI guarantees.
> > diff -r --unified glib-2.8.6/glib/glib.symbols gmod/glib/glib.symbols
> > --- glib-2.8.6/glib/glib.symbols        2005-08-29 18:12:15.000000000 
> > -0400
> > +++ gmod/glib/glib.symbols      2006-03-15 10:27:44.126612200 -0500
> > @@ -1243,7 +1243,6 @@
> > #if IN_FILE(__G_WIN32_H__)
> > #ifdef G_OS_WIN32
> > g_win32_error_message
> > -g_win32_ftruncate
> > g_win32_get_package_installation_directory PRIVATE
> > g_win32_get_package_installation_directory_utf8
> > g_win32_get_package_installation_subdirectory PRIVATE
> > diff -r --unified glib-2.8.6/glib/gwin32.h gmod/glib/gwin32.h
> > --- glib-2.8.6/glib/gwin32.h    2005-04-27 05:50:09.000000000 -0400
> > +++ gmod/glib/gwin32.h  2006-03-15 10:27:21.907293400 -0500
> > @@ -61,8 +63,13 @@
> >  * g_win32_. Or that was the idea at some time, but there is just one
> >  * of those:
> >  */
> > -gint           g_win32_ftruncate       (gint            f,
> > -                                        guint           size);
> > +
> > +/* Use supplied MinGW function */
> > +#define ftruncate g_win32_ftruncate
> > +
> > + gint          g_win32_ftruncate       (gint            f,
> > +                                        guint           size);
> > +
> > #endif /* G_OS_WIN32 */
> >
> > /* The MS setlocale uses locale names of the form "English_United
> >
> >
> >
> >
> >
> > ################################################################################## 
> >
> >
> > And I also had to add the following changes to the makefiles, in 
> > order to build static versions of all 4 libraries:
> There is just glib and gobject provided as static lib to get a 
> self-contained glib-genmarshal.exe. These static libs are meant to
> be internal to GLib and are not the supported way to use GLib and 
> gobject.
>
>
> > [...]
> >
> > All this gets me 4 static libraries (glib-2.8s.lib, gmodule-2.8s.lib, 
> > gobject-2.8s.lib, gthread-2.8s.lib).
> >
> > However, the end result is that I am trying to compile wvWare, which 
> > ultimately complains with the following errors:
> >
> > undefined reference to `__imp__g_thread_functions_for_glib_use'
> > undefined reference to `__imp__g_threads_got_initialized'
> > (repeated many times)
> >
> > What could I possibly be doing wrong?
> You are trying to use incomplete static libs.
>
> > I did notice that inside gthread, gthread-win32.c does NOT get 
> > compiled, only gthread-impl.c. Does this seem right?
> from config.h
>
> /* Source file containing theread implementation */
> #define G_THREAD_SOURCE "gthread-win32.c"
>
> and gthread-impl.c has
> #include G_THREAD_SOURCE
>
> > imp__g_thread_functions_for_glib_use does not seem to be used in any 
> > of the source files, indeed th eonly text file that does contain it 
> > is "gobject/libgobject-2.0-0.map".
> the 'imp' prefix is name mangling added by the compiler and stands
> for this needs to be imported from somewhere. It gets 'magically' defined
> if you link the right files.
>
>     Hans
>
> -------- Hans "at" Breuer "dot" Org -----------
> Tell me what you need, and I'll tell you how to
> get along without it.                -- Dilbert