interfaces for such runtime functionality as an event loop, threads,
dynamic loading, and an object system.
-The official ftp site is:
+The official download locations are:
ftp://ftp.gtk.org/pub/glib
+ http://download.gnome.org/sources/glib
The official web site is:
http://www.gtk.org/
Information about mailing lists can be found at
- http://www.gtk.org/mailinglists.html
+ http://www.gtk.org/mailing-lists.php
-To subscribe: mail -s subscribe gtk-list-request@gnome.org < /dev/null
-(Send mail to gtk-list-request@gnome.org with the subject "subscribe")
+To subscribe, send mail to gtk-list-request@gnome.org
+with the subject "subscribe".
Installation
============
See the file 'INSTALL'
+How to report bugs
+==================
+
+Bugs should be reported to the GNOME bug tracking system.
+(http://bugzilla.gnome.org, product glib.) You will need
+to create an account for yourself.
+
+In the bug report please include:
+
+* Information about your system. For instance:
+
+ - What operating system and version
+ - For Linux, what version of the C library
+
+ And anything else you think is relevant.
+
+* How to reproduce the bug.
+
+ If you can reproduce it with one of the test programs that are built
+ in the tests/ subdirectory, that will be most convenient. Otherwise,
+ please include a short test program that exhibits the behavior.
+ As a last resort, you can also provide a pointer to a larger piece
+ of software that can be downloaded.
+
+* If the bug was a crash, the exact text that was printed out
+ when the crash occured.
+
+* Further information such as stack traces may be useful, but
+ is not necessary.
+
+Patches
+=======
+
+Patches should also be submitted to bugzilla.gnome.org. If the
+patch fixes an existing bug, add the patch as an attachment
+to that bug report.
+
+Otherwise, enter a new bug report that describes the patch,
+and attach the patch to that bug report.
+
+Patches should be in unified diff form. (The -up option to GNU diff.)
+
+Notes about GLib 2.40
+=====================
+
+* g_test_run() no longer runs tests in exactly the order they are
+ registered; instead, it groups them according to test suites (ie,
+ path components) like the documentation always claimed it did. In
+ some cases, this can result in a sub-optimal ordering of tests,
+ relative to the old behavior. The fix is to change the test paths to
+ properly group together the tests that should run together. (eg, if
+ you want to run test_foo_simple(), test_bar_simple(), and
+ test_foo_using_bar() in that order, they should have test paths like
+ "/simple/foo", "/simple/bar", "/complex/foo-using-bar", not
+ "/foo/simple", "/bar/simple", "/foo/using-bar" (which would result
+ in test_foo_using_bar() running before test_bar_simple()).
+
+ (The behavior actually changed in GLib 2.36, but it was not
+ documented at the time, since we didn't realize it mattered.)
+
+Notes about GLib 2.36
+=====================
+
+* It is no longer necessary to call g_type_init(). If you are
+ loading GLib as a dynamic module, you should be careful to avoid
+ unloading it, then subsequently loading it again. This never
+ really worked before, but it is now explicitly undefined behavior.
+ Note that if g_type_init() was the only explicit use of a GObject
+ API and you are using linker flags such as --no-add-needed, then
+ you may have to artificially use some GObject call to keep the
+ linker from optimizing away -lgobject. We recommend to use
+ g_type_ensure (G_TYPE_OBJECT) for this purpose.
+
+* This release contains an incompatible change to the g_get_home_dir()
+ function. Previously, this function would effectively ignore the HOME
+ environment variable and always return the value from /etc/password.
+ As of this version, the HOME variable is used if it is set and the
+ value from /etc/passwd is only used as a fallback.
+
+* The 'flowinfo' and 'scope_id' fields of GInetSocketAddress
+ (introduced in GLib 2.32) have been fixed to be in host byte order
+ rather than network byte order. This is an incompatible change, but
+ the previous behavior was clearly broken, so it seems unlikely that
+ anyone was using it.
+
+Notes about GLib 2.34
+=====================
+
+* GIO now looks for thumbnails in XDG_CACHE_HOME, following a
+ recent alignment of the thumbnail spec with the basedir spec.
+
+* The default values for GThreadPools max_unused_threads and
+ max_idle_time settings have been changed to 2 and 15*1000,
+ respectively.
+
+Notes about GLib 2.32
+=====================
+
+* It is no longer necessary to use g_thread_init() or to link against
+ libgthread. libglib is now always thread-enabled. Custom thread
+ system implementations are no longer supported (including errorcheck
+ mutexes).
+
+* The thread and synchronisation APIs have been updated.
+ GMutex and GCond can be statically allocated without explicit
+ initialisation, as can new types GRWLock and GRecMutex. The
+ GStatic_______ variants of these types have been deprecated. GPrivate
+ can also be statically allocated and has a nicer API (deprecating
+ GStaticPrivate). Finally, g_thread_create() has been replaced with a
+ substantially simplified g_thread_new().
+
+* The g_once_init_enter()/_leave() functions have been replaced with
+ macros that allow for a pointer to any gsize-sized object, not just a
+ gsize*. The assertions to ensure that a pointer to a correctly-sized
+ object is being used will not work with generic pointers (ie: (void*)
+ and (gpointer) casts) which would have worked with the old version.
+
+* It is now mandatory to include glib.h instead of individual headers.
+
+* The -uninstalled variants of the pkg-config files have been dropped.
+
+* For a long time, gobject-2.0.pc mistakenly declared a public
+ dependency on gthread-2.0.pc (when the dependency should have been
+ private). This means that programs got away with calling
+ g_thread_init() without explicitly listing gthread-2.0.pc among their
+ dependencies.
+
+ gthread has now been removed as a gobject dependency, which will cause
+ such programs to break.
+
+ The fix for this problem is either to declare an explicit dependency
+ on gthread-2.0.pc (if you care about compatibility with older GLib
+ versions) or to stop calling g_thread_init().
+
+* g_debug() output is no longer enabled by default. It can be enabled
+ on a per-domain basis with the G_MESSAGES_DEBUG environment variable
+ like
+ G_MESSAGES_DEBUG=domain1,domain2
+ or
+ G_MESSAGES_DEBUG=all
+
+Notes about GLib 2.30
+=====================
+
+* GObject includes a generic marshaller, g_cclosure_marshal_generic.
+ To use it, simply specify NULL as the marshaller in g_signal_new().
+ The generic marshaller is implemented with libffi, and consequently
+ GObject depends on libffi now.
+
+Notes about GLib 2.28
+=====================
+
+* The GApplication API has changed compared to the version that was
+ included in the 2.25 development snapshots. Existing users will need
+ adjustments.
+
+Notes about GLib 2.26
+=====================
+
+* Nothing noteworthy.
+
Notes about GLib 2.24
=====================
connected to dies, just disables it. See the API docs for the function
for further details and the correct workaround that will continue to
work with future versions of GLib.
-
-How to report bugs
-==================
-
-Bugs should be reported to the GNOME bug tracking system.
-(http://bugzilla.gnome.org, product glib.) You will need
-to create an account for yourself.
-
-In the bug report please include:
-
-* Information about your system. For instance:
-
- - What operating system and version
- - For Linux, what version of the C library
-
- And anything else you think is relevant.
-
-* How to reproduce the bug.
-
- If you can reproduce it with one of the test programs that are built
- in the tests/ subdirectory, that will be most convenient. Otherwise,
- please include a short test program that exhibits the behavior.
- As a last resort, you can also provide a pointer to a larger piece
- of software that can be downloaded.
-
-* If the bug was a crash, the exact text that was printed out
- when the crash occured.
-
-* Further information such as stack traces may be useful, but
- is not necessary.
-
-Patches
-=======
-
-Patches should also be submitted to bugzilla.gnome.org. If the
-patch fixes an existing bug, add the patch as an attachment
-to that bug report.
-
-Otherwise, enter a new bug report that describes the patch,
-and attach the patch to that bug report.
-
-Patches should be in unified diff form. (The -up option to GNUdiff.)
projects / platform / upstream / glib.git / blobdiff