GLib 概览

GLib是一个通用实用程序库，它提供了许多有用的数据类型、宏、类型转换、字符串实用程序、文件实用程序、主循环抽象等等。它可以在许多类似 UNIX 的平台上工作，也可以在 Windows 和 osx 上工作。GLib 是根据 GNU 通用公共许可证（GNU-Lesser-General-Public-License，GNU-LGPL）发布的。

编译 GLib 软件包

在 UNIX 上编译软件包

On UNIX, GLib uses the standard GNU build system, using autoconf for package configuration and resolving portability issues,automake for building makefiles that comply with the GNU Coding Standards, and libtool for building shared libraries on multiple platforms. The normal sequence for compiling and installing the GLib library is thus:

        ./configure
        make
        make install

The standard options provided by GNU autoconf may be passed to the configure script. Please see the autoconf documentation or run ./configure --help for information about the standard options.

GLib is compiled with strict aliasing disabled. It is strongly recommended that this is not re-enabled by overriding the compiler flags, as GLib has not been tested with strict aliasing and cannot be guaranteed to work.

The GTK+ documentation contains further details about the build process and ways to influence it.

依赖项

Before you can compile the GLib library, you need to have various other tools and libraries installed on your system. If you are building from a release archive, you will need a compliant C toolchain, GNU Make, and pkg-config; if you are building directly from a Git repository clone of GLib, you will also need the GNU Autotools mentioned above.

pkg-config is a tool for tracking the compilation flags needed for libraries that are used by the GLib library. (For each library, a small .pc text file is installed in a standard location that contains the compilation flags needed for that library along with version number information).
The GLib Makefiles make use of several features specific to GNU make, and will not build correctly with other versions of make. You will need to install it if you don't already have it on your system. (It may be called gmake rather than make.)

A UNIX build of GLib requires that the system implements at least the original 1990 version of POSIX. Beyond this, it depends on a number of other libraries.

The GNU libiconv library is needed to build GLib if your system doesn't have the iconv() function for doing conversion between character encodings. Most modern systems should have iconv(), however many older systems lack an iconv() implementation. On such systems, you must install the libiconv library. This can be found at: http://www.gnu.org/software/libiconv.

If your system has an iconv() implementation but you want to use libiconv instead, you can pass the --with-libiconv option to configure. This forces libiconv to be used.

Note that if you have libiconv installed in your default include search path (for instance, in /usr/local/), but don't enable it, you will get an error while compiling GLib because the iconv.h that libiconv installs hides the system iconv.

If you are using the native iconv implementation on Solaris instead of libiconv, you'll need to make sure that you have the converters between locale encodings and UTF-8 installed. At a minimum you'll need the SUNWuiu8 package. You probably should also install the SUNWciu8, SUNWhiu8, SUNWjiu8, and SUNWkiu8 packages.

The native iconv on Compaq Tru64 doesn't contain support for UTF-8, so you'll need to use GNU libiconv instead. (When using GNU libiconv for GLib, you'll need to use GNU libiconv for GNU gettext as well.) This probably applies to related operating systems as well.
The libintl library from the GNU gettext package is needed if your system doesn't have the gettext() functionality for handling message translation databases.
A thread implementation is needed. The thread support in GLib can be based upon POSIX threads or win32 threads.
GRegex uses the PCRE library for regular expression matching. The default is to use the system version of PCRE, to reduce the chances of security fixes going out of sync. GLib additionally provides an internal copy of PCRE in case the system version is too old, or does not support UTF-8; the internal copy is patched to use GLib for memory management and to share the same Unicode tables.
The optional extended attribute support in GIO requires the getxattr() family of functions that may be provided by the C library or by the standalone libattr library. To build GLib without extended attribute support, use the --disable-xattr option.
The optional SELinux support in GIO requires libselinux. To build GLib without SELinux support, use the --disable-selinuxoption.
The optional support for DTrace requires the sys/sdt.h header, which is provided by SystemTap on Linux. To build GLib without DTrace, use the --disable-dtrace configure option.
The optional support for SystemTap can be disabled with the --disable-systemtap configure option. Additionally, you can control the location where GLib installs the SystemTap probes, using the --with-tapset-install-dir=DIR configure option.

其他配置选项

In addition to the normal options, the configure script in the GLib library supports these additional arguments:

--enable-debug. Turns on various amounts of debugging support. Setting this to 'no' disables g_assert(), g_return_if_fail(),g_return_val_if_fail() and all cast checks between different object types. Setting it to 'minimum' disables only cast checks. Setting it to 'yes' enables runtime debugging. The default is 'minimum' for stable releases, and 'yes' for development snapshots. Note that 'no' is fast, but dangerous as it tends to destabilize even mostly bug-free software by changing the effect of many bugs from simple warnings into fatal crashes. Thus --enable-debug=no should not be used for stable releases of GLib.

--disable-gc-friendly and --enable-gc-friendly. By default, and with --disable-gc-friendly as well, GLib does not clear the memory for certain objects before they are freed. For example, GLib may decide to recycle GList nodes by putting them in a free list. However, memory profiling and debugging tools like Valgrind work better if an application does not keep dangling pointers to freed memory (even though these pointers are no longer dereferenced), or invalid pointers inside uninitialized memory. The --enable-gc-friendly option makes GLib clear memory in these situations:

When shrinking a GArray, GLib will clear the memory no longer available in the array: shrink an array from 10 bytes to 7, and the last 3 bytes will be cleared. This includes removals of single and multiple elements.
When growing a GArray, GLib will clear the new chunk of memory. Grow an array from 7 bytes to 10 bytes, and the last 3 bytes will be cleared.
The above applies to GPtrArray as well.
When freeing a node from a GHashTable, GLib will first clear the node, which used to have pointers to the key and the value stored at that node.
When destroying or removing a GTree node, GLib will clear the node, which used to have pointers to the node's value, and the left and right subnodes.

Since clearing the memory has a cost, --disable-gc-friendly is the default.

--disable-mem-pools and --enable-mem-pools. Many small chunks of memory are often allocated via collective pools in GLib and are cached after release to speed up reallocations. For sparse memory systems this behaviour is often inferior, so memory pools can be disabled to avoid excessive caching and force atomic maintenance of chunks through the g_malloc() and g_free() functions. Code currently affected by this:

GMemChunks become basically non-effective
GSignal disables all caching (potentially very slow)
GType doesn't honour the GTypeInfo n_preallocs field anymore
the GBSearchArray flag G_BSEARCH_ALIGN_POWER2 becomes non-functional

--with-threads. Specify a thread implementation to use. Available options are 'posix' or 'win32'. Normally, configure should be able to work out the system threads API on its own.

--with-pcre. Specify whether to use the internal or the system-supplied PCRE library.

'internal' means that GRegex will be compiled to use the internal PCRE library.
'system' means that GRegex will be compiled to use the system-supplied PCRE library; this is the default setting.

Using the internal PCRE is the preferred solution if:

your system has strict resource constraints; the system-supplied PCRE has a separated copy of the tables used for Unicode handling, whereas the internal copy shares the Unicode tables used by GLib.
your system has PCRE built without some needed features, such as UTF-8 and Unicode support.
you are planning to use both GRegex and PCRE API at the same time, either directly or indirectly through a dependency; PCRE uses some global variables for memory management and other features, and if both GLib and PCRE try to access them at the same time, this could lead to undefined behavior.

--disable-included-printf and --enable-included-printf. By default the configure script will try to auto-detect whether the C library provides a suitable set of printf() functions. In detail, configure checks that the semantics of snprintf() are as specified by C99 and that positional parameters as specified in the Single Unix Specification are supported. If this not the case, GLib will include an implementation of the printf() family. These options can be used to explicitly control whether an implementation of the printf()family should be included or not.

--disable-Bsymbolic and --enable-Bsymbolic. By default, GLib uses the -Bsymbolic-functions linker flag to avoid intra-library PLT jumps. A side-effect of this is that it is no longer possible to override internal uses of GLib functions with LD_PRELOAD. Therefore, it may make sense to turn this feature off in some situations. The --disable-Bsymbolic option allows to do that.

--disable-gtk-doc and --enable-gtk-doc. By default the configure script will try to auto-detect whether the gtk-doc package is installed. If it is, then it will use it to extract and build the documentation for the GLib library. These options can be used to explicitly control whether gtk-doc should be used or not. If it is not used, the distributed, pre-generated HTML files will be installed instead of building them on your machine.

--disable-man and --enable-man. By default the configure script will try to auto-detect whether xsltproc and the necessary Docbook stylesheets are installed. If they are, then it will use them to rebuild the included man pages from the XML sources. These options can be used to explicitly control whether man pages should be rebuilt used or not. The distribution includes pre-generated man pages.

--disable-xattr and --enable-xattr. By default the configure script will try to auto-detect whether the getxattr() family of functions is available. If it is, then extended attribute support will be included in GIO. These options can be used to explicitly control whether extended attribute support should be included or not. getxattr() and friends can be provided by glibc or by the standalone libattr library.

--disable-selinux and --enable-selinux. By default the configure script will auto-detect if libselinux is available and include SELinux support in GIO if it is. These options can be used to explicitly control whether SELinux support should be included.

--disable-dtrace and --enable-dtrace. By default the configure script will detect if DTrace support is available, and use it.

--disable-systemtap and --enable-systemtap. This option requires DTrace support. If it is available, then the configure script will also check for the presence of SystemTap.

--enable-coverage and --disable-coverage. Enable the generation of coverage reports for the GLib tests. This requires the lcov frontend to gcov from the Linux Test Project. To generate a coverage report, use the lcov make target. The report is placed in the glib-lcov directory.

--with-runtime-libdir=RELPATH. Allows specifying a relative path to where to install the runtime libraries (meaning library files used for running, not developing, GLib applications). This can be used in operating system setups where programs using GLib needs to run before e.g. /usr is mounted. For example, if LIBDIR is /usr/lib and ../../lib is passed to --with-runtime-libdir then the runtime libraries are installed into /lib rather than /usr/lib.

--with-python=PATH. Allows specifying the Python interpreter to use, either as an absolute path, or as a program name. GLib can be built with Python 2 (at least version 2.7) or, preferably, with Python 3.

交叉编译 GLib 软件包

在不同架构体系下编译软件包

Cross-compilation is the process of compiling a program or library on a different architecture or operating system then it will be run upon. GLib is slightly more difficult to cross-compile than many packages because much of GLib is about hiding differences between different systems.

These notes cover things specific to cross-compiling GLib; for general information about cross-compilation, see the autoconf info pages.

GLib tries to detect as much information as possible about the target system by compiling and linking programs without actually running anything; however, some information GLib needs is not available this way. This information needs to be provided to the configure script via a "cache file" or by setting the cache variables in your environment.

As an example of using a cache file, to cross compile for the "MingW32" Win32 runtime environment on a Linux system, create a file 'win32.cache' with the following contents:

glib_cv_long_long_format=I64
glib_cv_stack_grows=no

Then execute the following commands:

PATH=/path/to/mingw32-compiler/bin:$PATH
chmod a-w win32.cache   # prevent configure from changing it
./configure --cache-file=win32.cache --host=mingw32

The complete list of cache file variables follows. Most of these won't need to be set in most cases.

缓存文件变量

glib_cv_long_long_format=[ll/q/I64]. Format used by printf() and scanf() for 64 bit integers. "ll" is the C99 standard, and what is used by the 'trio' library that GLib builds if your printf() is insufficiently capable. Doesn't need to be set if you are compiling using trio.

glib_cv_stack_grows=[yes/no]. Whether the stack grows up or down. Most places will want "no", A few architectures, such as PA-RISC need "yes".

glib_cv_working_bcopy=[yes/no]. Whether your bcopy() can handle overlapping copies. Only needs to be set if you don't havememmove(). (Very unlikely)

glib_cv_sane_realloc=[yes/no]. Whether your realloc() conforms to ANSI C and can handle NULL as the first argument. Defaults to "yes" and probably doesn't need to be set.

glib_cv_have_strlcpy=[yes/no]. Whether you have strlcpy() that matches OpenBSD. Defaults to "no", which is safe, since GLib uses a built-in version in that case.

glib_cv_have_qsort_r=[yes/no]. Whether you have qsort_r() that matches BSD. Defaults to "no", which is safe, since GLib uses a built-in version in that case.

glib_cv_va_val_copy=[yes/no]. Whether va_list can be copied as a pointer. If set to "no", then memcopy() will be used. Only matters if you don't have va_copy() or __va_copy(). (So, doesn't matter for GCC.) Defaults to "yes" which is slightly more common than "no".

glib_cv_rtldglobal_broken=[yes/no]. Whether you have a bug found in OSF/1 v5.0. Defaults to "no".

glib_cv_uscore=[yes/no]. Whether an underscore needs to be prepended to symbols when looking them up via dlsym(). Only needs to be set if your system uses dlopen()/dlsym().

ac_cv_func_posix_getpwuid_r=[yes/no]. Whether you have a getpwuid_r function (in your C library, not your thread library) that conforms to the POSIX spec. (Takes a 'struct passwd **' as the final argument)

ac_cv_func_nonposix_getpwuid_r=[yes/no]. Whether you have some variant of getpwuid_r() that doesn't conform to to the POSIX spec, but GLib might be able to use (or might segfault.) Only needs to be set if ac_cv_func_posix_getpwuid_r is not set. It's safest to set this to "no".

ac_cv_func_posix_getgrgid_r=[yes/no]. Whether you have a getgrgid_r function that conforms to the POSIX spec.

glib_cv_use_pid_surrogate=[yes/no]. Whether to use a setpriority() on the PID of the thread as a method for setting the priority of threads. This only needs to be set when using POSIX threads.

ac_cv_func_printf_unix98=[yes/no]. Whether your printf() family supports Unix98 style %N$ positional parameters. Defaults to "no".

ac_cv_func_vsnprintf_c99=[yes/no]. Whether you have a vsnprintf() with C99 semantics. (C99 semantics means returning the number of bytes that would have been written had the output buffer had enough space.) Defaults to "no".

编写 GLib 应用程序

编写 Glib 应用程序

线程

The general policy of GLib is that all functions are invisibly threadsafe with the exception of data structure manipulation functions, where, if you have two threads manipulating the same data structure, they must use a lock to synchronize their operation.

GLib creates a worker thread for its own purposes so GLib applications will always have at least 2 threads.

See the sections on threads and threadpools for GLib APIs that support multithreaded applications.

安全

When writing code that runs with elevated privileges, it is important to follow some basic rules of secure programming. David Wheeler has an excellent book on this topic, Secure Programming for Linux and Unix HOWTO.

When it comes to GLib and its associated libraries, GLib and GObject are generally fine to use in code that runs with elevated privileges; they don't load modules (executable code in shared objects) or run other programs 'behind your back'. GIO has to be used carefully in privileged programs, see the GIO documentation for details.

编译 GLib 应用程序

在 UNIX 系统上编译 GLib 应用程序

To compile a GLib application, you need to tell the compiler where to find the GLib header files and libraries. This is done with thepkg-config utility.

The following interactive shell session demonstrates how pkg-config is used (the actual output on your system may be different):

$ pkg-config --cflags glib-2.0
 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
$ pkg-config --libs glib-2.0
 -L/usr/lib -lm -lglib-2.0

See the pkg-config website for more information about pkg-config.

If your application uses or GObject features, it must be compiled and linked with the options returned by the following pkg-configinvocation:

$ pkg-config --cflags --libs gobject-2.0

If your application uses modules, it must be compiled and linked with the options returned by one of the following pkg-configinvocations:

$ pkg-config --cflags --libs gmodule-no-export-2.0
$ pkg-config --cflags --libs gmodule-2.0

The difference between the two is that gmodule-2.0 adds --export-dynamic to the linker flags, which is often not needed.

The simplest way to compile a program is to use the "backticks" feature of the shell. If you enclose a command in backticks (not single quotes), then its output will be substituted into the command line before execution. So to compile a GLib Hello, World, you would type the following:

$ cc hello.c `pkg-config --cflags --libs glib-2.0` -o hello

Note that the name of the file must come before the other options (such as pkg-config), or else you may get an error from the linker.

Deprecated GLib functions are annotated to make the compiler emit warnings when they are used (e.g. with gcc, you need to use the -Wdeprecated-declarations option). If these warnings are problematic, they can be turned off by defining the preprocessor symbol GLIB_DISABLE_DEPRECATION_WARNINGS by using the commandline option -DGLIB_DISABLE_DEPRECATION_WARNINGS

GLib deprecation annotations are versioned; by defining the macros GLIB_VERSION_MIN_REQUIRED and GLIB_VERSION_MAX_ALLOWED, you can specify the range of GLib versions whose API you want to use. APIs that were deprecated before or introduced after this range will trigger compiler warnings.

The older deprecation mechanism of hiding deprecated interfaces entirely from the compiler by using the preprocessor symbol G_DISABLE_DEPRECATED is still used for deprecated macros, enumeration values, etc. To detect uses of these in your code, use the commandline option -DG_DISABLE_DEPRECATED.

The recommended way of using GLib has always been to only include the toplevel headers glib.h, glib-object.h, gio.h. Starting with 2.32, GLib enforces this by generating an error when individual headers are directly included.

Still, there are some exceptions; these headers have to be included separately: gmodule.h, glib-unix.h, glib/gi18n-lib.h orglib/gi18n.h (see the Internationalization section), glib/gprintf.h and glib/gstdio.h (we don't want to pull in all of stdio).

运行 GLib 应用程序

运行和调试 GLib 应用程序

环境变量

The runtime behaviour of GLib applications can be influenced by a number of environment variables.

Standard variables. GLib reads standard environment variables like LANG, PATH, HOME, TMPDIR, TZ and LOGNAME.

XDG directories. GLib consults the environment variables XDG_DATA_HOME, XDG_DATA_DIRS, XDG_CONFIG_HOME, XDG_CONFIG_DIRS, XDG_CACHE_HOME and XDG_RUNTIME_DIR for the various XDG directories. For more information, see the XDG basedir spec.

G_FILENAME_ENCODING. This environment variable can be set to a comma-separated list of character set names. GLib assumes that filenames are encoded in the first character set from that list rather than in UTF-8. The special token "@locale" can be used to specify the character set for the current locale.

G_BROKEN_FILENAMES. If this environment variable is set, GLib assumes that filenames are in the locale encoding rather than in UTF-8. G_FILENAME_ENCODING takes priority over G_BROKEN_FILENAMES.

G_MESSAGES_PREFIXED. A list of log levels for which messages should be prefixed by the program name and PID of the application. The default is to prefix everything except G_LOG_LEVEL_MESSAGE and G_LOG_LEVEL_INFO. The possible values are error, warning, critical,message, info and debug. You can also use the special values all and help. This environment variable only affects the default log handler, g_log_default_handler().

G_MESSAGES_DEBUG. A space-separated list of log domains for which informational and debug messages should be printed. By default, these messages are not printed. You can also use the special value all. This environment variable only affects the default log handler, g_log_default_handler().

G_DEBUG. This environment variable can be set to a list of debug options, which cause GLib to print out different types of debugging information.

fatal-warnings	Causes GLib to abort the program at the first call to g_warning() or g_critical().
fatal-criticals	Causes GLib to abort the program at the first call to g_critical().
gc-friendly	Newly allocated memory that isn't directly initialized, as well as memory being freed will be reset to 0. The point here is to allow memory checkers and similar programs that use Boehm GC alike algorithms to produce more accurate results.
resident-modules	All modules loaded by GModule will be made resident. This can be useful for tracking memory leaks in modules which are later unloaded; but it can also hide bugs where code is accessed after the module would have normally been unloaded.
bind-now-modules	All modules loaded by GModule will bind their symbols at load time, even when the code uses %G_MODULE_BIND_LAZY.

The special value all can be used to turn on all debug options. The special value help can be used to print all available options.

G_SLICE. This environment variable allows reconfiguration of the GSlice memory allocator.

always-malloc

This will cause all slices allocated through g_slice_alloc() and released by g_slice_free1() to be actually allocated via direct calls to g_malloc() and g_free(). This is most useful for memory checkers and similar programs that use Boehm GC alike algorithms to produce more accurate results. It can also be in conjunction with debugging features of the system's malloc() implementation such as glibc's MALLOC_CHECK_=2 to debug erroneous slice allocation code, although debug-blocks is usually a better suited debugging tool.

debug-blocks

Using this option (present since GLib 2.13) engages extra code which performs sanity checks on the released memory slices. Invalid slice addresses or slice sizes will be reported and lead to a program halt. This option is for debugging scenarios. In particular, client packages sporting their own test suite should always enable this option when running tests. Global slice validation is ensured by storing size and address information for each allocated chunk, and maintaining a global hash table of that data. That way, multi-thread scalability is given up, and memory consumption is increased. However, the resulting code usually performs acceptably well, possibly better than with comparable memory checking carried out using external tools.

An example of a memory corruption scenario that cannot be reproduced with G_SLICE=always-malloc, but will be caught by G_SLICE=debug-blocks is as follows:

void *slist = g_slist_alloc (); /* void* gives up type-safety */
            g_list_free (slist);            /* corruption: sizeof (GSList) != sizeof (GList) */

The special value all can be used to turn on all options. The special value help can be used to print all available options.

G_RANDOM_VERSION. If this environment variable is set to '2.0', the outdated pseudo-random number seeding and generation algorithms from GLib 2.0 are used instead of the newer, better ones. You should only set this variable if you have sequences of numbers that were generated with Glib 2.0 that you need to reproduce exactly.

LIBCHARSET_ALIAS_DIR. Allows to specify a nonstandard location for the charset.aliases file that is used by the character set conversion routines. The default location is the libdir specified at compilation time.

TZDIR. Allows to specify a nonstandard location for the timezone data files that are used by the #GDateTime API. The default location is under /usr/share/zoneinfo. For more information, also look at the tzset manual page.

G_ENABLE_DIAGNOSTIC. If set to a non-zero value, this environment variable enables diagnostic messages, like deprecation messages for GObject properties and signals.

本地化

A number of interfaces in GLib depend on the current locale in which an application is running. Therefore, most GLib-using applications should call setlocale (LC_ALL, "") to set up the current locale.

On Windows, in a C program there are several locale concepts that not necessarily are synchronized. On one hand, there is the system default ANSI code-page, which determines what encoding is used for file names handled by the C library's functions and the Win32 API. (We are talking about the "narrow" functions here that take character pointers, not the "wide" ones.)

On the other hand, there is the C library's current locale. The character set (code-page) used by that is not necessarily the same as the system default ANSI code-page. Strings in this character set are returned by functions like strftime().

GLib ships with a set of Python macros for the GDB debugger. These includes pretty printers for lists, hashtables and GObject types. It also has a backtrace filter that makes backtraces with signal emissions easier to read.

To use this you need a version of GDB that supports Python scripting; anything from 7.0 should be fine. You then need to install GLib in the same prefix as GDB so that the Python GDB autoloaded files get installed in the right place for GDB to pick up.

General pretty printing should just happen without having to do anything special. To get the signal emission filtered backtrace you must use the "new-backtrace" command instead of the standard one.

There is also a new command called gforeach that can be used to apply a command on each item in a list. E.g. you can do

gforeach i in some_list_variable: print *(GtkWidget *)l

Which would print the contents of each widget in a list of widgets.

SystemTap

SystemTap is a dynamic whole-system analysis toolkit. GLib ships with a file libglib-2.0.so.*.stp which defines a set of probe points, which you can hook into with custom SystemTap scripts. See the files libglib-2.0.so.*.stp, libgobject-2.0.so.*.stp and libgio-2.0.so.*.stp which are in your shared SystemTap scripts directory.

Memory statistics

g_mem_profile() will output a summary g_malloc() memory usage, if memory profiling has been enabled by calling g_mem_set_vtable (glib_mem_profiler_table) upon startup.

If GLib has been configured with --enable-debug=yes, then g_slice_debug_tree_statistics() can be called in a debugger to output details about the memory usage of the slice allocator.

GLib 修改变更

Incompatible changes from 2.0 to 2.2

GLib changed the seeding algorithm for the pseudo-random number generator Mersenne Twister, as used by GRand and GRandom. This was necessary, because some seeds would yield very bad pseudo-random streams. Also the pseudo-random integers generated by g_rand*_int_range() will have a slightly better equal distribution with the new version of GLib.

Further information can be found at the website of the Mersenne Twister random number generator at http://www.math.keio.ac.jp/~matumoto/emt.html.

The original seeding and generation algorithms, as found in GLib 2.0.x, can be used instead of the new ones by setting the environment variable G_RANDOM_VERSION to the value of '2.0'. Use the GLib-2.0 algorithms only if you have sequences of numbers generated with Glib-2.0 that you need to reproduce exactly.

Incompatible changes from 1.2 to 2.0

The event loop functionality GMain has extensively been revised to support multiple separate main loops in separate threads. All sources (timeouts, idle functions, etc.) are associated with a GMainContext.

Compatibility functions exist so that most application code dealing with the main loop will continue to work. However, code that creates new custom types of sources will require modification.

The main changes here are:
- Sources are now exposed as GSource *, rather than simply as numeric ids.
- New types of sources are created by structure "derivation" from GSource, so the source_data parameter to the GSourcevirtual functions has been replaced with a GSource *.
- Sources are first created, then later added to a specific GMainContext.
- Dispatching has been modified so both the callback and data are passed in to the dispatch() virtual function.
To go along with this change, the vtable for GIOChannel has changed and add_watch() has been replaced by create_watch().
g_list_foreach() and g_slist_foreach() have been changed so they are now safe against removal of the current item, not the next item.

It's not recommended to mutate the list in the callback to these functions in any case.
GDate now works in UTF-8, not in the current locale. If you want to use it with the encoding of the locale, you need to convert strings using g_locale_to_utf8() first.
g_strsplit() has been fixed to:
- include trailing empty tokens, rather than stripping them
- split into a maximum of max_tokens tokens, rather than max_tokens + 1
Code depending on either of these bugs will need to be fixed.
Deprecated functions that got removed: g_set_error_handler(), g_set_warning_handler(), g_set_message_handler(), useg_log_set_handler() instead.

邮件清单和缺陷报告

填写缺陷报告或特色需求

If you encounter a bug, misfeature, or missing feature in GLib, please file a bug report on http://bugzilla.gnome.org. We'd also appreciate reports of incomplete or misleading information in the GLib documentation; file those against the "docs" component of the "glib" product in Bugzilla.

Don't hesitate to file a bug report, even if you think we may know about it already, or aren't sure of the details. Just give us as much information as you have, and if it's already fixed or has already been discussed, we'll add a note to that effect in the report.

The bug tracker should definitely be used for feature requests, it's not only for bugs. We track all GLib development in Bugzilla, so it's the way to be sure the GLib developers won't forget about an issue.

提交补丁

If you develop a bugfix or enhancement for GLib, please file that in Bugzilla as well. Bugzilla allows you to attach files; please attach a patch generated by the diff utility, using the -u option to make the patch more readable. All patches must be offered under the terms of the GNU LGPL license, so be sure you are authorized to give us the patch under those terms.

If you want to discuss your patch before or after developing it, mail gtk-devel-list@gnome.org. But be sure to file the Bugzilla report as well; if the patch is only on the list and not in Bugzilla, it's likely to slip through the cracks.

邮件清单

There are several mailing lists dedicated to GTK+ and related libraries. Discussion of GLib generally takes place on these lists. You can subscribe or view the archives of these lists on http://mail.gnome.org.

gtk-list@gnome.org	gtk-list covers general GTK+ (and GLib) topics; questions about using GLib in programs, GLib from a user standpoint, announcements of GLib-related projects would all be on-topic. The bulk of the traffic consists of GTK+ programming questions.
gtk-devel-list@gnome.org	gtk-devel-list is for discussion of work on GTK+ (and GLib) itself, it is not for asking questions about how to use GTK+ (or GLib) in applications. gtk-devel-list is appropriate for discussion of patches, bugs, proposed features, and so on.
gtk-doc-list@gnome.org	gtk-doc-list is for discussion of the gtk-doc documentation system (used to document GTK+ and Glib), and for work on the GTK+ (and GLib) documentation.