That's odd as obviously GLib 2.22 and later versions have been building fine for me and many others, but compiled natively on Windows, or cross-compiled from Linux. What OS are you compiling on? I see pathnames like /home/pete; does that mean you are using Cygwin? (In that case, are you sure you understand the difference between Cygwin and "native" Windows, and that using mingw means compiling for "native" Windows? And is the gcc you are using then the Cygwin one or the mingw one?) 

Presumably you are not cross-compilation from Linux as you apparently use the path /usr/local as your target prefix? And what is /local/include? 

Are you trying to build without thread support? That is not supported. (But on the other hand, you do use the -mthreads option.) What did you configure line look like?

(In the first sentence above, I meant to write "both" and not "but".)

No-no cygwin! MSYS is what I'm using :) (info about msys mingw.org) Configure line looked like
./configure CFLAGS="-I/local/include -O2" CPPFLAGS="-I/local/include" LDFLAGS="-L/local/lib -Wl,--enable-auto-image-base" --with-threads=none --enable-threads=no CC="gcc -mthreads"
I managed to build glib-2.24.0 with these config options, but the bug, described above, is still there.. I went in "lamer way" and changed few lines in glib-2.24.0/gio/gcancellable.c:
line: 369
  while (priv->cancelled_running)
    {
      priv->cancelled_running_waiting = FALSE;
//      g_cond_wait (cancellable_cond,
//                   g_static_mutex_get_mutex (& G_LOCK_NAME (cancellable)));
    }

line: 761
  while (priv->cancelled_running)
    {
      priv->cancelled_running_waiting = FALSE;
//      g_cond_wait (cancellable_cond,
//                   g_static_mutex_get_mutex (& G_LOCK_NAME (cancellable)));
    }

I'm not sure how wrong it was, but all compiled fine then.. Now I'm going to try to build pkg-config against it and see how it works. "-mthreads" flag adviced in README.win32 file.

Well, as I said, it is (apparently) not supported to build without thread support, at least not for Windows. If that is intentional, that the configure script provides such options is a bug then. If you don't want thread support, why then bother with -mthreads? That doesn't make much sense.

The same error happens on Linux, too, if one configures GLib with --enable-threads=no. Changing summary accordingly.

I didn't know what -mthreads is there for.. I'm a beginner :) Ok, so I can link against pthreadsGC2.dll and i'll solve the error?

*pthreadGC2.dll
and enable threading in config

Don't mix in pthreads when building GLib on Windows, that is totally unnecessary, as GLib itself calls the necessary underlying Win32 APIs (unless you bypass that with --with-threads=none and/or --enable-threads=no).

I really don't understand what your goal is, on one hand you for some reason have decided to explicitly pass --with-threads=none, which is not a normal thing to do, so it seems to me that you have decided you want to build a GLib that doesn't implement any of the thread-related GLib APIs?

(But as can be seen in the compilation error, that doesn't seem to be supported, and whether this is intentional or not is what this bug report is about, i.e. should the possibility to use --with-threads=none and --enable-threads=no be removed, if we de facto don't want those to be ever used?)

But you now then talk about mixing in the pthreads DLL? If you don't want threading APIs to work in GLib, why would you still want to mix in pthreads in some way?

Am I on the right track now?
./configure CFLAGS="-I/local/include -O2" CPPFLAGS=-I/local/include LDFLAGS="-L/local/lib -Wl,--enable-auto-image-base"  CC="gcc -mthreads" --disable-static

Got:
make[3]: Entering directory `/home/pete/installed/glib-2.24.0/gthread'
/bin/sh ../libtool  --tag=CC   --mode=link gcc -mthreads  -I/local/include -O2 -mms-bitfields -Wall -Wl,gthread-win32-res.o -version-info 2400:0:2400 -export-dynamic -no-undefined -export-symbols ./gthread.def -L/local/lib -Wl,--enable-auto-image-base -o libgthread-2.0.la -rpath /usr/local/lib gthread-impl.lo   ../glib/libglib-2.0.la -lintl  
libtool: link: rm -fr  .libs/libgthread-2.0.dll.a
libtool: link: if test "x`/bin/sed 1q ./gthread.def`" = xEXPORTS; then cp ./gthread.def .libs/libgthread-2.0-0.dll.def; else echo EXPORTS > .libs/libgthread-2.0-0.dll.def; cat ./gthread.def >> .libs/libgthread-2.0-0.dll.def; fi
libtool: link:  gcc -mthreads -shared .libs/libgthread-2.0-0.dll.def  .libs/gthread-impl.o   -L/local/lib ../glib/.libs/libglib-2.0.dll.a -lws2_32 -lole32 /usr/local/lib/libintl.dll.a -lpthreadGC2  -mthreads -mms-bitfields -Wl,gthread-win32-res.o -Wl,--enable-auto-image-base   -mthreads -o .libs/libgthread-2.0-0.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libgthread-2.0.dll.a
Creating library file: .libs/libgthread-2.0.dll.a
libtool: link: warning: `/local/lib/libintl.la' seems to be moved
.libs/gthread-impl.o:gthread-impl.c:(.text+0x1813): undefined reference to `_g_thread_init_glib'
collect2: ld returned 1 exit status
make[3]: *** [libgthread-2.0.la] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

glib.def is not exporting "g_thread_init_glib".. why?

glib.def does export g_thread_init_glib for me when I build glib.

g_thread_init_glib is listed in glib.symbols inside #ifdef INCLUDE_INTERNAL_SYMBOLS, and the command in Makefile.am to generate glib.def from glib.symbols does pass  -DINCLUDE_INTERNAL_SYMBOLS to $(CPP).

I still see -lpthreadGC2 in your command output. Where does it come from?

Anyway, your problems now are not related to what this bug report is about ("Building glib fails when using --enable-threads=no", on all platforms.)

Bugzilla is not supposed to be a help forum. Please discuss your problems in building GLib on an appropriate mailing list (gtk-devel?) instead. Or come to #gtk+ on irc.gimp.org. (Do *not* send me personal mail.)

ok, thanks for your help, I compiled everything alright :) -lpthreadGC2 comes as libintl dependancy.

This bug, as it is now summarized, is *not* fixed. Building GLib still fails (on all systems), as far as I know, if one tries to use --enable-threads=no.

Oh, I removed --enable-threads=no, and built it alright. This so this thread can be closed with "notabug"?

No. This bug is not any longer about your problem.

This bug is that if one uses --enable-threads=no it doesn't build (on any platform). Either we should remove the possibility to use --enable-threads=no, or fix it so that it does build in that case, too.

I think we just want to stop supporting --enable-threads=no

*** Bug 621010 has been marked as a duplicate of this bug. ***

Created attachment 163097 [details] [review]
Allow build to continue with --disable-threads

This patch basically allows the definition of the reference lock, but because other parts of the code check is threads is supported this ends up as a no-op, which is just what we want.

I am encountering the same build error with --enable-threads=no on Cygwin (traceback is below). If I enable threads, then starting any GTK program immediately causes a segmentation fault. Alan Hourihane's patch allows me to build glib with --enable-threads=no, and GTK programs then run correctly.


/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..  -DG_
LOG_DOMAIN=\"GLib-GIO\" -I.. -I../glib -I../glib -I.. -I../gmodule -DG_DISABLE_C
AST_CHECKS -DG_THREADS_MANDATORY -DG_DISABLE_DEPRECATED -DGIO_COMPILATION -DGIO_
MODULE_DIR=\"/usr/local/lib/gio/modules\"  -DG_DISABLE_SINGLE_INCLUDES  -g -O2 -
Wall -MT gcancellable.lo -MD -MP -MF .deps/gcancellable.Tpo -c -o gcancellable.l
o gcancellable.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -DG_LOG_DOMAIN=\"GLib-GIO\" -I..
 -I../glib -I../glib -I.. -I../gmodule -DG_DISABLE_CAST_CHECKS -DG_THREADS_MANDA
TORY -DG_DISABLE_DEPRECATED -DGIO_COMPILATION -DGIO_MODULE_DIR=\"/usr/local/lib/
gio/modules\" -DG_DISABLE_SINGLE_INCLUDES -g -O2 -Wall -MT gcancellable.lo -MD -
MP -MF .deps/gcancellable.Tpo -c gcancellable.c  -DDLL_EXPORT -DPIC -o .libs/gca
ncellable.o
gcancellable.c: In function 'g_cancellable_reset':
gcancellable.c:371: error: 'g__cancellable_lock' undeclared (first use in this f
unction)
gcancellable.c:371: error: (Each undeclared identifier is reported only once
gcancellable.c:371: error: for each function it appears in.)
gcancellable.c: In function 'g_cancellable_disconnect':
gcancellable.c:766: error: 'g__cancellable_lock' undeclared (first use in this f
unction)
make[4]: *** [gcancellable.lo] Error 1

Michiel, I think it would be more useful to fix whatever problem it is that causes GTK+ programs on Cygwin to crash if you have built GLib with threads enabled. (You should open a separate bug for that.)

I am fairly sure that the consensus among maintainers is that building GLib without thread support is not something we really want people to be able to do, and that it appears to be possible (even if it requires a small patch to then compile?) is a mistake. Especially if we talk about bleeding-edge GLib.

Especially note mclasen's comment #16.

Makes sense. I opened a separate bug #631211 for this issue.

(In reply to comment #20)
> Michiel, I think it would be more useful to fix whatever problem it is that
> causes GTK+ programs on Cygwin to crash if you have built GLib with threads
> enabled. (You should open a separate bug for that.)

Created attachment 176198 [details] [review]
Remove redundant g_thread_init() calls

g_type_init() calls g_thread_init() (if threads are available), so
there's no point in (unconditionally) calling both.

Created attachment 176199 [details] [review]
Make threads mandatory

G_THREADS_ENABLED still exists, but is always defined. It is still
possible to use libglib without threads, but gobject (and everything
above it) is now guaranteed to be using threads (as, in fact, it was
before, since it was accidentally impossible to compile with
--disable-threads).

Created attachment 176200 [details] [review]
Remove !g_thread_supported() codepaths in gio

In particular, remove the libasyncns import, which was only used by
GUnixResolver, which is only used when threads are not available.
Likewise remove GWin32Resolver, and the hacky broken non-threaded
parts of GIOScheduler.

(In reply to comment #23)
> Created an attachment (id=176198) [details] [review]
> Remove redundant g_thread_init() calls

(this patch is correct even if we didn't want to kill off --enable-threads=no, so I did it separately)

Created attachment 195333 [details] [review]
Make threads mandatory

Updated this patch to apply to current glib master.

Created attachment 195334 [details] [review]
Remove !g_thread_supported() codepaths in gio

In particular, remove the libasyncns import, which was only used by
GUnixResolver, which is only used when threads are not available.
Likewise remove GWin32Resolver, and the hacky broken non-threaded
parts of GIOScheduler.

Created attachment 195335 [details] [review]
Revert "GIOSchedulerJob: Improve struct packing"

This reverts commit a2094d5e564433ed3a4398afeacce80519bbda44.

We need this in order for the previous patch to apply cleanly.

I think this is all taken care of