General Information
===================
-This is GLib version 1.1.0. GLib, is a library which includes support
-routines for C such as lists, trees, hashes, memory allocation, and
-many other things.
-
-Versions of GLib prior to 1.1.0 are distributed with GTK+ versions 1.1.0
-and earlier.
+This is GLib version 2.5.4. GLib is the low-level core
+library that forms the basis for projects such as GTK+ and GNOME. It
+provides data structure handling for C, portability wrappers, and
+interfaces for such runtime functionality as an event loop, threads,
+dynamic loading, and an object system.
The official ftp site is:
ftp://ftp.gtk.org/pub/gtk
The official web site is:
http://www.gtk.org/
-A mailing list is located at:
- gtk-list@redhat.com
+Information about mailing lists can be found at
+ http://www.gtk.org/mailinglists.html
-To subscribe: mail -s subscribe gtk-list-request@redhat.com < /dev/null
-(Send mail to gtk-list-request@redhat.com with the subject "subscribe")
+To subscribe: mail -s subscribe gtk-list-request@gnome.org < /dev/null
+(Send mail to gtk-list-request@gnome.org with the subject "subscribe")
Installation
============
See the file 'INSTALL'
+Notes about GLib-2.4.0
+======================
+
+* GObject now enforces CONSTRUCT_ONLY properties; due to an oversight
+ in previous versions, it was possible to set CONSTRUCT_ONLY properties
+ after construct time.
+
+* The child watch functionality tends to reveal a bug in many
+ thread implementations (in particular the older LinuxThreads implementation
+ on Linux) where it's not possible to call waitpid() for a child
+ created in a different thread. For this reason, for maximum portability,
+ you should structure your code to fork all child processes that you want
+ to wait for from the main thread.
+
+* A problem was recently discovered with g_signal_connect_object();
+ it doesn't actually disconnect the signal handler once the object being
+ 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
==================
-To report a bug, send mail either to gtk-list, as mentioned
-above, or to gtk-bugs@gtk.org. If you send mail to gtk-list, you
-must be subscribed yourself.
-
-In the mail include:
+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.
-* The version of GLib
+In the bug report please include:
* Information about your system. For instance:
- What operating system and version
- - What version of X
- 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 the testglib program that is built
- in the glib/ directory, that will be most convenient. Otherwise,
+ If you can reproduce it with the testgtk program that is built
+ in the gtk/ 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.
Patches
=======
-Patches can be uploaded to the incoming/ directory on
-ftp.gtk.org. Please follow the instructions there, and include
-your name and email address in the README file.
+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.
+
+Bug reports containing patches should include the PATCH keyword
+in their keyword fields. If the patch adds to or changes the GLib
+programming interface, the API keyword should also be included.
-If the patch fixes a bug, it is usually a good idea to include
-all the information described in "How to Report Bugs".
+Patches should be in unified diff form. (The -u option to GNU
+diff.)
projects / platform / upstream / glib.git / blobdiff