mirror of
https://gitlab.gnome.org/GNOME/glib.git
synced 2024-12-25 06:56:14 +01:00
fdf83b5108
Patch by Thomas Andersen, bug 647594
234 lines
9.4 KiB
Plaintext
234 lines
9.4 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/glib
|
|
|
|
The official web site is:
|
|
http://www.gtk.org/
|
|
|
|
Information about mailing lists can be found at
|
|
http://www.gtk.org/mailing-lists.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.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
|
|
=====================
|
|
|
|
* It is now allowed to call g_thread_init(NULL) multiple times, and
|
|
to call glib functions before g_thread_init(NULL) is called
|
|
(although the later is mainly a change in docs as this worked before
|
|
too). See the GThread reference documentation for the details.
|
|
|
|
* GObject now links to GThread and threads are enabled automatically
|
|
when g_type_init() is called.
|
|
|
|
* GObject no longer allows to call g_object_set() on construct-only properties
|
|
while an object is being initialized. If this behavior is needed, setting a
|
|
custom constructor that just chains up will re-enable this functionality.
|
|
|
|
* GMappedFile on an empty file now returns NULL for the contents instead of
|
|
returning an empty string. The documentation specifically states that code
|
|
may not rely on nul-termination here so any breakage caused by this change
|
|
is a bug in application code.
|
|
|
|
Notes about GLib 2.22
|
|
=====================
|
|
|
|
* Repeated calls to g_simple_async_result_set_op_res_gpointer used
|
|
to leak the data. This has been fixed to always call the provided
|
|
destroy notify.
|
|
|
|
Notes about GLib 2.20
|
|
=====================
|
|
|
|
* The functions for launching applications (e.g. g_app_info_launch() +
|
|
friends) now passes a FUSE file:// URI if possible (requires gvfs
|
|
with the FUSE daemon to be running and operational). With gvfs 2.26,
|
|
FUSE file:// URIs will be mapped back to gio URIs in the GFile
|
|
constructors. The intent of this change is to better integrate
|
|
POSIX-only applications, see bug #528670 for the rationale. The
|
|
only user-visible change is when an application needs to examine an
|
|
URI passed to it (e.g. as a positional parameter). Instead of
|
|
looking at the given URI, the application will now need to look at
|
|
the result of g_file_get_uri() after having constructed a GFile
|
|
object with the given URI.
|
|
|
|
Notes about GLib 2.18
|
|
=====================
|
|
|
|
* The recommended way of using GLib has always been to only include the
|
|
toplevel headers glib.h, glib-object.h and gio.h. GLib enforces this by
|
|
generating an error when individual headers are directly included.
|
|
To help with the transition, the enforcement is not turned on by
|
|
default for GLib headers (it is turned on for GObject and GIO).
|
|
To turn it on, define the preprocessor symbol G_DISABLE_SINGLE_INCLUDES.
|
|
|
|
Notes about GLib 2.16
|
|
=====================
|
|
|
|
* GLib now includes GIO, which adds optional dependencies against libattr
|
|
and libselinux for extended attribute and SELinux support. Use
|
|
--disable-xattr and --disable-selinux to build without these.
|
|
|
|
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.
|
|
|
|
* 'make check' has been changed to validate translations by calling
|
|
msgfmt with the -c option. As a result, it may fail on systems with
|
|
older gettext implementations (GNU gettext < 0.14.1, or Solaris gettext).
|
|
'make check' will also fail on systems where the C compiler does not
|
|
support ELF visibility attributes.
|
|
|
|
* The GMemChunk API has been deprecated in favour of a new 'slice
|
|
allocator'. See the g_slice documentation for more details.
|
|
|
|
* A new type, GInitiallyUnowned, has been introduced, which is
|
|
intended to serve as a common implementation of the 'floating reference'
|
|
concept that is e.g. used by GtkObject. Note that changing the
|
|
inheritance hierarchy of a type can cause problems for language
|
|
bindings and other code which needs to work closely with the type
|
|
system. Therefore, switching to GInitiallyUnowned should be done
|
|
carefully. g_object_compat_control() has been added to GLib 2.8.5
|
|
to help with the transition.
|
|
|
|
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
|
|
==================
|
|
|
|
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.)
|