| Summary: | games-board/aisleriot-3.2.3.2-r1: ./.libs/libaisleriot.a(libaisleriot_la-ar-runtime.o): In function `ar_runtime_init': ar-runtime.c:(.text+0x178): undefined reference to `g_thread_init' | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Oschtan <dawnstyle> |
| Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 406437 | ||
| Attachments: | build.log | ||
|
Description
Oschtan
2012-08-27 08:03:54 UTC
Created attachment 322346 [details]
build.log
Most likely that call should be surrounded by '#if !GLIB_CHECK_VERSION(2, 32, 0)...#endif'. gthread was removed from gobject-2.0.pc in 2.32, but at the same time glib started to init threads unconditionally on its own. (In reply to comment #2) > gthread was removed from gobject-2.0.pc in 2.32, but at the same time glib > started to init threads unconditionally on its own. Actually, g_type_init has called g_thread_init unconditionally since glib-2.24 iirc. I can't reproduce this particular build failure in aisleriot-3.2.3.2-r1 - I am guessing that one of aisleriot's dependencies on my machine is surreptitiously providing gthread - but in cvs I've now added a patch from aisleriot-3.4 that should fix it. > 28 Aug 2012; Alexandre Rostovtsev <tetromino@gentoo.org> > aisleriot-3.2.3.2-r1.ebuild, +files/aisleriot-3.2.3.2-g_thread_init.patch: > Fix g_thread_init/glib-2.32 build failure (bug #432938, thanks to Oschtan). (In reply to comment #3) > > Actually, g_type_init has called g_thread_init unconditionally since > glib-2.24 iirc. > > I can't reproduce this particular build failure in aisleriot-3.2.3.2-r1 - I > am guessing that one of aisleriot's dependencies on my machine is > surreptitiously providing gthread - but in cvs I've now added a patch from > aisleriot-3.4 that should fix it. > I was referring to the changes listed on top of "Overview of changes from GLib 2.29/2.30 to 2.31.0" section of glib NEWS, in particular: "threading is now always enabled in GLib". That's why such #ifdef block should be a valid change. (In reply to comment #4) > (In reply to comment #3) > > > > Actually, g_type_init has called g_thread_init unconditionally since > > glib-2.24 iirc. > > > > I can't reproduce this particular build failure in aisleriot-3.2.3.2-r1 - I > > am guessing that one of aisleriot's dependencies on my machine is > > surreptitiously providing gthread - but in cvs I've now added a patch from > > aisleriot-3.4 that should fix it. > > > > I was referring to the changes listed on top of "Overview of changes from > GLib 2.29/2.30 to 2.31.0" section of glib NEWS, in particular: "threading is > now always enabled in GLib". > That's why such #ifdef block should be a valid change. Threading has been de facto always enabled in glib since at least 2.22 days because glib simply failed to build when configured with --disable-threads :) g_type_init has automatically called g_thread_init since 2.23.2, see http://git.gnome.org/browse/glib/commit/?id=fa2bced1f30f93443ef43ce8b5b1e437cd07168c The changes in 2.31.0 were that the --disable-threads configure switch was finally removed; and that g_thread_init, which had been useless for years (since g_type_init called it), was now explicitly deprecated, and attempts to call it started causing build failures. (In reply to comment #5) > Threading has been de facto always enabled in glib since at least 2.22 days > because glib simply failed to build when configured with --disable-threads :) > > g_type_init has automatically called g_thread_init since 2.23.2, see > http://git.gnome.org/browse/glib/commit/ > ?id=fa2bced1f30f93443ef43ce8b5b1e437cd07168c > > The changes in 2.31.0 were that the --disable-threads configure switch was > finally removed; and that g_thread_init, which had been useless for years > (since g_type_init called it), was now explicitly deprecated, and attempts > to call it started causing build failures. Not quite correct. There's no build failure related to using g_thread_init, but it's pointless and if called with non-NULL, it prints a warning about incorrect use (that has i.e. bit wine in regard of gstreamer). IIUC, this commit: http://git.gnome.org/browse/glib/commit/?id=47444dacc069be5984df4064ae382d45a9ae8c9e made threads initialized upon library load. |
