Sebastian Wilhelmi 5e7134375e Added the missing POSIX_NO_YIELD and POSIX_NO_PRIORITIES warning messages.
2000-03-17  Sebastian Wilhelmi  <wilhelmi@ira.uka.de>

	* configure.in: Added the missing POSIX_NO_YIELD and
	POSIX_NO_PRIORITIES warning messages.

	* configure.in: Use AC_TRY_RUN instead of AC_TRY_LINK, to test for
	real thread support. On solaris pthread_create can be linked to
	even in -lc, but it doesn't work then.

	* configure.in: Don't use priorities for threads, when the
	minimal/maximal priorities couldn't be determined at configure
	time.

	* configure.in, gthread.c: Always define GSystemThread in
	glibconfig.h to represent a system thread.

	* configure.in: Do not use native recursive threads, when
	possibe. We use some features, that they do not expose (namely the
	depth counter).

	* glib.h, gthread.c: Redefined GStaticRecMutex. The functions are
	now implemented in a different way, which should be way
	faster. Alsothere are now functions g_static_rec_mutex_unlock_full
	and g_static_rec_mutex_lock_full to leave/enter a recursive mutex
	completly.

	* gthread.c (g_thread_self): Do not test the system_thread to be
	non-zero to speed things up.

	* gthread.c (g_mutex_init): Therefore set the system_thread of the
	main thread here.

	* tests/thread-test.c: Rerun all tests once again, but this time
	we fool the system into thinking, that the available thread system
	is not native, but userprovided.

	* gthread/gthread-posix.c: Don't use priorities for threads,
	when the minimal/maximal priorities couldn't be determined at
	configure time.

	* gthread/gthread-posix.c: Don't check for errors, when
	setting the scope of a tread to system, as some posix
	implementations can't do that and we don't want the thing to
	fail because of that.
2000-03-17 14:49:59 +00:00
2000-03-01 09:44:32 +00:00
1999-06-02 18:43:45 +00:00
1999-10-04 23:04:34 +00:00
1999-08-17 17:41:01 +00:00
2000-03-01 09:44:10 +00:00
2000-03-01 09:44:10 +00:00
2000-03-01 09:44:10 +00:00
2000-03-01 09:44:10 +00:00
2000-03-01 09:44:10 +00:00
2000-03-01 09:44:10 +00:00
1999-11-08 09:49:10 +00:00
1999-01-20 23:06:30 +00:00
2000-03-01 09:44:10 +00:00

 *** IMPORTANT *** 

This is a development version of GLib.  You should be using a stable
version, which is available at ftp://ftp.gtk.org/pub/gtk/v1.2/.  This
version is meant for developers of GLib only:

 * You should not base stable software on this version of GLib.
 * GNOME developers should use a stable version of GLib.

Distributions should *NOT* ship a development package of this GLib.
Do not ship the headers and do not ship the glib-config script.  These
things will conflict with the stable 1.2 series.  Package only enough
to satisfy the requirements of some other package.  Package only the
library itself.  Doing otherwise will do no favors to the community.

If you install this version of GLib, we strongly recommend that you
install it in a different prefix than GLib 1.2.  Use --prefix as an
argument to configure to do this.  Otherwise, you will not be able to
do development with GLib 1.2 any longer.

*** You should be using GLib 1.2 instead. ***


General Information
===================

This is GLib version 1.3.1. 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".
Description
Low-level core library that forms the basis for projects such as GTK+ and GNOME.
Readme 112 MiB
Languages
C 95.3%
Python 2.3%
Meson 1.3%
Objective-C 0.3%
Shell 0.2%
Other 0.5%