GLib is quickly moving towards initializing threads automatically at program startup. This is already the case for Gtk+ programs with GLib 2.24:
http://developer.gnome.org/glib/2.28/glib-Threads.html "Please note that since version 2.24 the GObject initialization function g_type_init() initializes threads (with a NULL argument), so most applications, including those using Gtk+ will run with threads enabled. If you want a special thread implementation, make sure you call g_thread_init() before g_type_init() is called." ...and it will be the case everywhere with GLib 2.32: http://git.gnome.org/browse/glib/tree/glib/gthread.c?h=master * The GLib threading system used to be initialized with g_thread_init(). * This is no longer necessary. Since version 2.32, the GLib threading * system is automatically initialized at the start of your program, * and all thread-creation functions and synchronization primitives * are available right away. Is there any reason we shouldn't remove the thread options from configure.in and CMakeOptions.txt along with USE_THREADS and hard-code thread support? ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe