X-Git-Url: http://review.tizen.org/git/?a=blobdiff_plain;f=README.in;h=6a86f85347ebeb45677540c95a98bc9fcdad3a9e;hb=9da85c7262325478e8730ae9f3e76bd0528a9a8c;hp=9f9c35d7846328ea34fd7bb81eef81ce9d8ea3f5;hpb=513be6bbaec4f6f8675feaa3a29a41a1d04af5e1;p=platform%2Fupstream%2Fglib.git diff --git a/README.in b/README.in index 9f9c35d..6a86f85 100644 --- a/README.in +++ b/README.in @@ -7,23 +7,244 @@ 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 download locations are: + ftp://ftp.gtk.org/pub/glib + http://download.gnome.org/sources/glib The official web site is: http://www.gtk.org/ Information about mailing lists can be found at - http://www.gtk.org/mailinglists.html + http://www.gtk.org/mailing-lists.php -To subscribe: mail -s subscribe gtk-list-request@gnome.org < /dev/null -(Send mail to gtk-list-request@gnome.org with the subject "subscribe") +To subscribe, send mail to gtk-list-request@gnome.org +with the subject "subscribe". Installation ============ See the file 'INSTALL' +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 GNU diff.) + +Notes about GLib 2.40 +===================== + +* g_test_run() no longer runs tests in exactly the order they are + registered; instead, it groups them according to test suites (ie, + path components) like the documentation always claimed it did. In + some cases, this can result in a sub-optimal ordering of tests, + relative to the old behavior. The fix is to change the test paths to + properly group together the tests that should run together. (eg, if + you want to run test_foo_simple(), test_bar_simple(), and + test_foo_using_bar() in that order, they should have test paths like + "/simple/foo", "/simple/bar", "/complex/foo-using-bar", not + "/foo/simple", "/bar/simple", "/foo/using-bar" (which would result + in test_foo_using_bar() running before test_bar_simple()). + + (The behavior actually changed in GLib 2.36, but it was not + documented at the time, since we didn't realize it mattered.) + +Notes about GLib 2.36 +===================== + +* It is no longer necessary to call g_type_init(). If you are + loading GLib as a dynamic module, you should be careful to avoid + unloading it, then subsequently loading it again. This never + really worked before, but it is now explicitly undefined behavior. + Note that if g_type_init() was the only explicit use of a GObject + API and you are using linker flags such as --no-add-needed, then + you may have to artificially use some GObject call to keep the + linker from optimizing away -lgobject. We recommend to use + g_type_ensure (G_TYPE_OBJECT) for this purpose. + +* This release contains an incompatible change to the g_get_home_dir() + function. Previously, this function would effectively ignore the HOME + environment variable and always return the value from /etc/password. + As of this version, the HOME variable is used if it is set and the + value from /etc/passwd is only used as a fallback. + +* The 'flowinfo' and 'scope_id' fields of GInetSocketAddress + (introduced in GLib 2.32) have been fixed to be in host byte order + rather than network byte order. This is an incompatible change, but + the previous behavior was clearly broken, so it seems unlikely that + anyone was using it. + +Notes about GLib 2.34 +===================== + +* GIO now looks for thumbnails in XDG_CACHE_HOME, following a + recent alignment of the thumbnail spec with the basedir spec. + +* The default values for GThreadPools max_unused_threads and + max_idle_time settings have been changed to 2 and 15*1000, + respectively. + +Notes about GLib 2.32 +===================== + +* It is no longer necessary to use g_thread_init() or to link against + libgthread. libglib is now always thread-enabled. Custom thread + system implementations are no longer supported (including errorcheck + mutexes). + +* The thread and synchronisation APIs have been updated. + GMutex and GCond can be statically allocated without explicit + initialisation, as can new types GRWLock and GRecMutex. The + GStatic_______ variants of these types have been deprecated. GPrivate + can also be statically allocated and has a nicer API (deprecating + GStaticPrivate). Finally, g_thread_create() has been replaced with a + substantially simplified g_thread_new(). + +* The g_once_init_enter()/_leave() functions have been replaced with + macros that allow for a pointer to any gsize-sized object, not just a + gsize*. The assertions to ensure that a pointer to a correctly-sized + object is being used will not work with generic pointers (ie: (void*) + and (gpointer) casts) which would have worked with the old version. + +* It is now mandatory to include glib.h instead of individual headers. + +* The -uninstalled variants of the pkg-config files have been dropped. + +* For a long time, gobject-2.0.pc mistakenly declared a public + dependency on gthread-2.0.pc (when the dependency should have been + private). This means that programs got away with calling + g_thread_init() without explicitly listing gthread-2.0.pc among their + dependencies. + + gthread has now been removed as a gobject dependency, which will cause + such programs to break. + + The fix for this problem is either to declare an explicit dependency + on gthread-2.0.pc (if you care about compatibility with older GLib + versions) or to stop calling g_thread_init(). + +* g_debug() output is no longer enabled by default. It can be enabled + on a per-domain basis with the G_MESSAGES_DEBUG environment variable + like + G_MESSAGES_DEBUG=domain1,domain2 + or + G_MESSAGES_DEBUG=all + +Notes about GLib 2.30 +===================== + +* GObject includes a generic marshaller, g_cclosure_marshal_generic. + To use it, simply specify NULL as the marshaller in g_signal_new(). + The generic marshaller is implemented with libffi, and consequently + GObject depends on libffi now. + +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 ===================== @@ -35,16 +256,28 @@ Notes about GLib 2.10 * 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. +* 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' 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 ====================== @@ -73,20 +306,20 @@ Notes about GLib 2.6.0 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 +* 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 + 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 +* 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 @@ -95,61 +328,14 @@ Notes about GLib 2.6.0 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 + 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 +* 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. - -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.)