mirror of
https://gitlab.gnome.org/GNOME/glib.git
synced 2024-12-25 15:06:14 +01:00
Low-level core library that forms the basis for projects such as GTK+ and GNOME.
5f17e39e2a
Wed Mar 17 01:46:28 1999 Tim Janik <timj@gtk.org> * merges from glib-1-2: Sun Mar 14 17:50:35 1999 Tim Janik <timj@gtk.org> * gmem.c (g_mem_chunk_*): changed a bunch of g_assert() statements to g_return_if_fail(). (g_mem_profile): (g_mem_chunk_print): (g_mem_chunk_info): removed some extraneous "\n"s at the end of the log messages. * gtimer.c (g_timer_*): changed a bunch of g_assert() statements to g_return_if_fail(). * grel.c (g_*): changed a bunch of g_assert() statements to g_return_if_fail() and added some extra ones to check relation != NULL. Tue Mar 9 23:25:50 1999 Tim Janik <timj@gtk.org> * configure.in: check for working realloc (NULL,). * gmem.c (g_realloc): use malloc() for initial allocation on systems where realloc(NULL,) will not work (this is the case on SunOS, reported by Tom Geiger). Mon Mar 8 07:42:08 1999 Tim Janik <timj@gtk.org> * ghook.c (g_hook_unref): when !hook_list->is_setup, wrap the flag around the call to g_hook_free() to avoid spurious warnings (happens during destruction phase). 1999-03-02 Sebastian Wilhelmi <wilhelmi@ira.uka.de> * gmem.c: Fixed a stupid cut'n'paste error of mine. Thanks to Friedrich Dominicus <Friedrich.Dominicus@inka.de> |
||
---|---|---|
debian | ||
docs | ||
glib | ||
gmodule | ||
gthread | ||
tests | ||
.cvsignore | ||
acconfig.h | ||
acglib.m4 | ||
acinclude.m4 | ||
AUTHORS | ||
autogen.sh | ||
ChangeLog | ||
ChangeLog.pre-1-2 | ||
ChangeLog.pre-2-0 | ||
ChangeLog.pre-2-2 | ||
ChangeLog.pre-2-4 | ||
ChangeLog.pre-2-6 | ||
ChangeLog.pre-2-8 | ||
ChangeLog.pre-2-10 | ||
ChangeLog.pre-2-12 | ||
config.guess | ||
config.h.win32 | ||
config.sub | ||
configure.in | ||
COPYING | ||
garray.c | ||
gbacktrace.c | ||
gcache.c | ||
gcompletion.c | ||
gdataset.c | ||
gdate.c | ||
gerror.c | ||
ghash.c | ||
ghook.c | ||
giochannel.c | ||
giounix.c | ||
giowin32.c | ||
glib-config.in | ||
glib.def | ||
glib.h | ||
glib.m4 | ||
glib.spec.in | ||
glibconfig.h.win32 | ||
glist.c | ||
gmain.c | ||
gmem.c | ||
gmessages.c | ||
gmutex.c | ||
gnode.c | ||
gprimes.c | ||
gqueue.c | ||
grel.c | ||
gscanner.c | ||
gslist.c | ||
gstack.c | ||
gstrfuncs.c | ||
gstring.c | ||
gtimer.c | ||
gtree.c | ||
gutils.c | ||
HACKING | ||
INSTALL | ||
ltconfig | ||
ltmain.sh | ||
Makefile.am | ||
makefile.msc | ||
NEWS | ||
README | ||
README.win32 | ||
sanity_check | ||
testgdate.c | ||
testgdateparser.c | ||
testglib.c |
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. 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 To subscribe: mail -s subscribe gtk-list-request@redhat.com < /dev/null (Send mail to gtk-list-request@redhat.com with the subject "subscribe") Installation ============ See the file 'INSTALL' 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: * The version of GLib * 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, 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 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. If the patch fixes a bug, it is usually a good idea to include all the information described in "How to Report Bugs".