mirror of
https://gitlab.gnome.org/GNOME/glib.git
synced 2024-11-10 03:16:17 +01:00
126 lines
4.9 KiB
Plaintext
126 lines
4.9 KiB
Plaintext
General Information
|
|
===================
|
|
|
|
This is GLib version @GLIB_VERSION@. 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/
|
|
|
|
Information about mailing lists can be found at
|
|
http://www.gtk.org/mailinglists.html
|
|
|
|
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.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. On Windows these wrappers use the
|
|
wide-character API to do the actual file handling, so applications
|
|
can handle file names containing any Unicode characters, not just
|
|
those in the system codepage. (Wide character API is not available
|
|
on Win9x.)
|
|
|
|
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 agains GLib 2.6 will actually use new names for the
|
|
functions. This is transparent to the programmer.
|
|
|
|
* 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.
|
|
|
|
* GLib uses a technique involving macros for reducing the amount of PLT
|
|
redirections which has the side effect that the names of internally used
|
|
GLib functions are prefixed with IA__. The g_return_if_fail() macros
|
|
strip this prefix away, but it will show up e.g. in a debugger.
|
|
|
|
* 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
|
|
==================
|
|
|
|
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 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.
|
|
|
|
* 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.
|
|
|
|
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.
|
|
|
|
Patches should be in unified diff form. (The -u option to GNU
|
|
diff.)
|