General Information
===================
-This is GLib version 1.2.0. GLib is a library which includes support
-routines for C such as lists, trees, hashes, memory allocation, and
-many other things.
+This is GLib version 2.9.1. 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.10
+=====================
+
+* The functions g_snprintf() and g_vsnprintf() have been removed from
+ the gprintf.h header, since they are already declared in glib.h. This
+ doesn't break documented use of gprintf.h, but people have been known
+ to include gprintf.h without including glib.h.
+
+* The Unicode support has been updated to Unicode 4.1. This adds several
+ new members to the GUnicodeBreakType enumeration.
+
+* The support for Solaris threads has been retired. Solaris has provided
+ POSIX threads for long enough now to have them available on every
+ Solaris platform.
+
+
+Notes about GLib 2.6.0
+======================
+
+* GLib 2.6 introduces the concept of 'GLib filename encoding', which is the
+ on-disk encoding on Unix, but UTF-8 on Windows. All GLib functions
+ returning or accepting pathnames have been changed to expect
+ filenames in this encoding, and the common POSIX functions dealing
+ with pathnames have been wrapped. These wrappers are declared in the
+ header <glib/gstdio.h> which must be included explicitly; it is not
+ included through <glib.h>.
+
+ On current (NT-based) Windows versions, where the on-disk file names
+ are Unicode, these wrappers use the wide-character API in the C
+ library. Thus applications can handle file names containing any
+ Unicode characters through GLib's own API and its POSIX wrappers,
+ not just file names restricted to characters in the system codepage.
+
+ To keep binary compatibility with applications compiled against
+ older versions of GLib, the Windows DLL still provides entry points
+ with the old semantics using the old names, and applications
+ compiled against GLib 2.6 will actually use new names for the
+ functions. This is transparent to the programmer.
+
+ When compiling against GLib 2.6, applications intended to be
+ portable to Windows must take the UTF-8 file name encoding into
+ consideration, and use the gstdio wrappers to access files whose
+ names have been constructed from strings returned from GLib.
+
+* Likewise, g_get_user_name() and g_get_real_name() have been changed
+ to return UTF-8 on Windows, while keeping the old semantics for
+ applications compiled against older versions of GLib.
+
+* The GLib uses an '_' prefix to indicate private symbols that
+ must not be used by applications. On some platforms, symbols beginning
+ with prefixes such as _g will be exported from the library, on others not.
+ In no case can applications use these private symbols. In addition to that,
+ GLib+ 2.6 makes several symbols private which were not in any installed
+ header files and were never intended to be exported.
+
+* To reduce code size and improve efficiency, GLib, when compiled
+ with the GNU toolchain, has separate internal and external entry
+ points for exported functions. The internal names, which begin with
+ IA__, may be seen when debugging a GLib program.
+
+* On Windows, GLib no longer opens a console window when printing
+ warning messages if stdout or stderr are invalid, as they are in
+ "Windows subsystem" (GUI) applications. Simply redirect stdout or
+ stderr if you need to see them.
+
+* 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 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.
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