Update. cvs/libc-ud-971026

1997-10-26 18:12  Ulrich Drepper  <drepper@cygnus.com>

	* libio/genops.c: Partial undo of last patch.
	* libio/stdfiles.c: Likewise.
	* libio/iofdopen.c: Use _IO_FILE_complete, not _IO_file_plus.
	* libio/iopopen.c: Likewise.
	* libio/iovdprintf.c: Likewise.
	* libio/libio.h: Remove duplicated `;'.
	* libio/stdio.c: Remove misleading comment.
	* libio/stdio.h: Declare standard streams as variables.

	* login/Makefile (distribute): Add README.utmpd.
	* login/README.utmpd: New file.
	Provided by Mark M. Kettenis <kettenis@phys.uva.nl>.

	* manual/job.texi: Document tcgetsid.
	* manual/pattern.texi: Document globfree.
	* manual/terminal.texi: Document B38400 ... B460800.

	* posix/confstr.c: Print "-D_FILE_OFFSET_SIZE=64" for _CS_LFS_CFLAGS.

	* posix/unistd.h: Add explanation of _POSIX_* constants.

	* posix/unists.h: Add prototypes for __pread, __pread64, __pwrite
	and __pwrite64.
	* sysdeps/generic/pread.c: Define as __pread and make pread weak alias.
	* sysdeps/generic/pread64.c: Likewise.
	* sysdeps/generic/pwrite.c: Likewise.
	* sysdeps/generic/pwrite64.c: Likewise.
	* sysdeps/posix/pread.c: Likewise.
	* sysdeps/posix/pwrite.c: Likewise.
	* sysdeps/posix/pread64.c: New file.
	* sysdeps/posix/pwrite64.c: Likewise.
	* sysdeps/unix/sysv/linux/Makefile [$(subdir)=posix] (sysdep_routines):
	Add s_pread64 and s_pwrite64.
	* sysdeps/unix/sysv/linux/pread.c: New file.
	* sysdeps/unix/sysv/linux/pread64.c: New file.
	* sysdeps/unix/sysv/linux/pwrite.c: New file.
	* sysdeps/unix/sysv/linux/pwrite64.c: New file.
	* sysdeps/unix/sysv/linux/s_pread64.c: New file.
	* sysdeps/unix/sysv/linux/s_pwrite64.c: New file.
	* sysdeps/unix/sysv/linux/syscalls.list: Add pread and pwrite.
	* sysdeps/unix/sysv/linux/alpha/pread64.c: New (empty) file.
	* sysdeps/unix/sysv/linux/alpha/pwrite64.c: New (empty) file.
	* sysdeps/unix/sysv/linux/sparc/sparc64/pread64.c: New (empty) file.
	* sysdeps/unix/sysv/linux/sparc/sparc64/pwrite64.c: New (empty) file.
	* sysdeps/unix/sysv/linux/alpha/syscalls.list: Add pread and pwrite
	with weak aliases for *64 functions.
	* sysdeps/unix/sysv/linux/sparc/sparc64/syscalls.list: Likewise.

	* string/bits/string2.h: Add casts to allow void * arguments.

	* sysdeps/i386/i486/bits/string.h: Define index and rindex only if
	__USE_BSD or __USE_XOPEN_EXTENDED.

	* sysdeps/unix/sysv/linux/bits/socket.h: Add SCM_RIGHTS and other
	SCM_* constants from kernel header.

	* termios/termios.h: Add prototype for tcgetsid.

1997-10-26 13:26  Thorsten Kukuk  <kukuk@vt.uni-paderborn.de>

	* sunrpc/clnt_perr.c: Add trailing '\0' to strings.

	* sunrpc/get_myaddr.c: Include rpc/clnt.h for prototypes.

	* sunrpc/pmap_clnt.c: Use get_myaddress from header file.

1997-10-26 05:26  Ulrich Drepper  <drepper@cygnus.com>

	* configure.in: Punt if any directory mentioned in the
	enable-add-on parameter does not exist.

1997-10-25 19:25  Ulrich Drepper  <drepper@cygnus.com>

	* termios/Makefile (routines): Add tcgetsid.
	* termios/tcgetsid.c: New file.
	Provided by Mark M. Kettenis <kettenis@phys.uva.nl>.

1997-10-25 18:56  Ulrich Drepper  <drepper@cygnus.com>

	* stdlib/stdlib.h: Remove mblen optimization.
	* stdlib/mblen.c: Rewrite to make sure global state is not changed.
	Reported by anderson@metrolink.com.

1997-10-19 21:51  Wolfram Gloger  <wg@wolfram.dent.med.uni-muenchen.de>

	* malloc/thread-m.h [_LIBC]:  Use new __libc_internal_tsd_{set,get}
	interface for thread-specific data.

1997-10-25 06:51  Ulrich Drepper  <drepper@cygnus.com>

	* elf/dl-addr.c: Use braces for correct logical grouping.
	Patch by Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>.

1997-10-18 09:15  Geoff Keating  <geoffk@ozemail.com.au>

	* io/ftwtest-sh: Sometimes /tmp is a symlink to somewhere more
	convenient; that caused this test to break.

	* sysdeps/powerpc/dl-machine.h: Fix typo.

	* sysdeps/powerpc/bits/fenv.h: Don't use floating-point registers
	when -msoft-float is in effect, because this causes compilation to
	stop.
	* sysdeps/powerpc/bits/mathinlines.h: Likewise.

	* rpm/template: Add description, use RPM flags rather than the ones
	used to build the spec.  Build in a temporary directory, not /.

	* elf/dl-lookup.c: Don't include _itoa.h, it's not used.
	* elf/dl-minimal.c: Use _itoa_word rather than _itoa.  It seems that
	_itoa is the only routine that ld.so uses that requires something
	from libgcc.a on powerpc, so it would be best to avoid it in ld.so.
	* elf/rtld.c: Likewise.
	* sysdeps/generic/_strerror.c: Likewise.
	* stdio-common/_itoa.c: Split out digits strings.
	* stdio-common/itoa-digits.c: New file.
	* stdio-common/Makefile: Add itoa-digits.

1997-10-21  Andreas Jaeger  <aj@arthur.rhein-neckar.de>

	* manual/filesys.texi (Scanning Directory Content): Document error
	case more.

	* dirent/scandir.c (scandir): Ignore errors from select function.
	Suggested by urbanw@cs.umu.se (closes PR libc/316).

1997-10-25 06:18  Ulrich Drepper  <drepper@cygnus.com>

	* sysdeps/unix/sysv/linux/sparc/sparc32/socket.S: Corrections.
	Patch by Erik Troan <ewt@redhat.com>.

1997-10-25 04:00  Ulrich Drepper  <drepper@cygnus.com>

	* sysdeps/generic/dl-cache.c (_dl_load_cache_lookup): Favour exact
	matching of version function if both the general (1) and
	glibc-specific (3) entry are present.

1997-10-22 18:47  Thorsten Kukuk  <kukuk@vt.uni-paderborn.de>

	* sunrpc/rpc/clnt.h: Add get_myaddress prototype.

	* nis/libnsl.map: Fix typo.

	* nis/nis_call.c: Fix memory leak.

1997-10-22 19:29  Ulrich Drepper  <drepper@cygnus.com>

	* sysdeps/generic/memcmp.c: Define __P if not defined before.
	Patch by Jim Meyering <meyering@eng.ascend.com>.

1997-10-21 22:09  Ulrich Drepper  <drepper@cygnus.com>

	* sysdeps/unix/sysv/linux/sys/prctl.h: New file by Richard Gooch
	<rgooch@atnf.csiro.au>.

1997-10-21 21:50  Ulrich Drepper  <drepper@cygnus.com>

	* misc/syslog.c (vsyslog): Open console with O_NOCTTY.
	Patch by Zack Weinberg <zack@rabi.phys.columbia.edu>.

1997-10-21 18:07  Ulrich Drepper  <drepper@cygnus.com>

	* posix/wordexp.c: Improve handling of $... expressions.
	Patch by Tim Waugh <tim@cyberelk.demon.co.uk>.

1997-10-21 16:12  Ulrich Drepper  <drepper@cygnus.com>

	* manual/string.texi: Correct return values of bcopy and bzero.
	Patch by Matthew Wilcox <willy@odie.barnet.ac.uk>.

1997-10-18 15:03  Philip Blundell  <Philip.Blundell@pobox.com>

	* sysdeps/unix/sysv/linux/bits/socket.h: Correct types of some
	elements in struct msghdr and struct cmsghdr, to keep in step with
	the kernel.

1997-10-17 22:29  Ulrich Drepper  <drepper@cygnus.com>

	* sysdeps/unix/sysv/linux/sparc/sparc32/init-first.h: Fix another
	bug in startup code.
	Patch by Eric Delaunay <delaunay@lix.polytechnique.fr>.

1997-10-16 20:17  Richard Henderson  <rth@cygnus.com>

	* sysdeps/unix/sysv/linux/sparc/sparc32/socket.S: Dump args to the
	stack and give the kernel a pointer.  Use the sysdep.h macros.

1997-10-17 04:07  Ulrich Drepper  <drepper@cygnus.com>

	* sysdeps/sparc/sparc32/elf/start.S: Calculate argv correctly.
	Patch by Eric Delaunay <delaunay@lix.polytechnique.fr>.

1997-10-16  Andreas Jaeger  <aj@arthur.rhein-neckar.de>

	* sysdeps/libm-ieee754/s_nextafterxf.c [!__STDC__]: Correct typo.

1997-10-16 14:50  Ulrich Drepper  <drepper@cygnus.com>

	* manual/pattern.texi: Document globfree.

1997-10-15 21:11  Philip Blundell  <Philip.Blundell@pobox.com>

	* sysdeps/unix/sysv/linux/net/if_packet.h: New file.
	* sysdeps/unix/sysv/linux/Makefile (sysdep_headers): Add
	net/if_packet.h.

	* sysdeps/unix/sysv/linux/net/if_arp.h (ARPHRD_ASH): New type, for
	64Mbps ASH.
	(ARPHRD_ETHER): This is used for 100Mbps networks too.

1997-10-15  Andreas Jaeger  <aj@arthur.rhein-neckar.de>

	* Makerules (install): Use full pathnames for linker script.
	This is to work around a limitation in `ld' while no better solution
	is possible.

1997-10-15  Andreas Jaeger  <aj@arthur.rhein-neckar.de>

	* malloc/malloc.c (mmap_chunk): Put inline before static in
	function definition to avoid compiler warning.
	(malloc_extend): Likewise.

	* sysdeps/generic/des_impl.c: Include "des.h" to avoid warning.

1997-10-15  Andreas Jaeger  <aj@arthur.rhein-neckar.de>

	* NEWS: Fix @gnu.ai.mit.edu -> @gnu.org.
	* README.template: Likewise.
	* db/makedb.c: Likewise.
	* elf/ldd.bash.in: Likewise.
	* elf/ldd.sh.in: Likewise.
	* intl/locale.alias: Likewise.
	* login/programs/utmpd.c: Likewise.
	* libio/stdfiles.c [!_IO_MTSAFE] (DEF_STDFILE): Fix parameter list.

1997-10-14  Andreas Schwab  <schwab@issan.informatik.uni-dortmund.de>

	* Rules: Remove all empty.* files.
	(shared-only-routines): Correct implementation.

1997-10-14  Andreas Schwab  <schwab@issan.informatik.uni-dortmund.de>

	* sysdeps/libm-ieee754/s_lrintl.c: Make compilable.
	* sysdeps/libm-ieee754/s_llrintl.c: Likewise.  Optimized.

1997-10-14  Andreas Schwab  <schwab@issan.informatik.uni-dortmund.de>

	* elf/ldd.bash.in: Only prepend ./ if the file contains no slash
	at all.
	* elf/ldd.sh.in: Likewise.

1997-10-14  Andreas Schwab  <schwab@issan.informatik.uni-dortmund.de>

	* sysdeps/m68k/sys/ucontext.h: New file.

1997-10-13  Andreas Schwab  <schwab@issan.informatik.uni-dortmund.de>

	* sysdeps/m68k/fpu/s_scalbln.c: New (empty) file.
	* sysdeps/m68k/fpu/s_scalblnf.c: New (empty) file.
	* sysdeps/m68k/fpu/s_scalblnl.c: New (empty) file.

	* sysdeps/m68k/fpu/s_scalbn.c: Add scalbln alias.
	* sysdeps/m68k/fpu/s_scalbnf.c: Adapted.
	* sysdeps/m68k/fpu/s_scalbnl.c: Adapted.

	* sysdeps/m68k/fpu/s_lrint.c: Add standard skeleton stuff.
	* sysdeps/m68k/fpu/s_lrintf.c: New file.
	* sysdeps/m68k/fpu/s_lrintl.c: New file.

	* sysdeps/m68k/fpu/bits/mathinline.h: Add fma and scalbln.  Update
	lrint and scalbn.
	(__m81_inline) [__cplusplus]: Define to __inline.

	* math/bits/mathcalls.h: Remove whitespace before second argument
	of __MATHDECL.  Add note explaining this.

1997-10-13  Andreas Schwab  <schwab@issan.informatik.uni-dortmund.de>

	* manual/arith.texi (Absolute Value): Spelling fix.

1997-10-13  Andreas Schwab  <schwab@issan.informatik.uni-dortmund.de>

	* malloc/obstack.h (obstack_empty_p) [!__GNUC__]: Properly
	parenthesize the macro parameter.

	* Rules: Remove rules to magically install <subdir>.h headers.

1 files changed, 285 insertions, 0 deletions

diff --git a/SNAP b/SNAP
new file mode 100644
index 0000000000..c1fc905f43
--- /dev/null
+++ b/SNAP
@@ -0,0 +1,285 @@
+			 GNU libc SNAPSHOT SYSTEM
+			    (general info)
+			   Updated 1997-9-26
+
+WHAT ARE GNU libc SNAPSHOTS
+---------------------------
+
+Snapshots are an "image" of the main glibc development tree, captured at a
+particular random instant in time.  When you use the snapshots, you should be
+able to maintain a local copy of libc that is no more than one day older than
+the official source tree used by the libc maintainers.
+
+The primary purpose of providing snapshots is to widen the group of motivated
+developers that would like to help test, debug, and enhance glibc, by providing
+you with access to the "latest and greatest" source.  This has several
+advantages, and several disadvantages.
+
+    First the advantages:
+
+    o	Once we have a large base of motivated testers using the snapshots,
+	this should provide good coverage across all currently supported
+	glibc hosts and targets.  If a new bug is introduced in glibc due to
+	fixing another bug or ongoing development, it should become
+	obvious much more quickly and get fixed before the next general
+	net release.  This should help to reduce the chances of glibc being
+	released to the general public with a major bug that went unnoticed
+	during the release cycle testing because they are machine dependent.
+	We hope to greatly improve glibc's stability and reliability by
+	involving more people and more execution environments in the
+	prerelease testing.
+
+    o	With access to the latest source, any diffs that you send to fix
+	bugs or add new features should be much easier for the glibc team
+	to merge into the official source base (after suitable review
+	of course).  This encourages us to merge your changes quicker,
+	while they are still "fresh".
+
+    o	Once your diffs are merged, you can obtain a new copy of glibc
+	containing your changes almost immediately.  Thus you do not
+	have to maintain local copies of your changes for any longer
+	than it takes to get them merged into the official source base.
+	This encourages you to send in changes quicker.
+
+    And the disadvantages:
+
+    o	The snapshot you get will be largely untested and of unknown quality.
+	It may fail to configure or compile.  It may have serious bugs.
+	You should always keep a copy of the last known working version
+	before updating to the current snapshot, or at least be able to
+	regenerate a working version if the latest snapshot is unusable
+	in your environment for some reason.
+
+	If a production version of glibc has a bug and a snapshot has the fix,
+	and you care about stability, you should put only the fix for that
+	particular problem into your production version.  Of course, if you
+	are eager to test glibc, you can use the snapshot versions in your
+	daily work, but users who have not been consulted about whether they
+	feel like testing glibc should generally have something which is at
+	least as bug free as the last released version.
+
+    o	Providing timely response to your questions, bug reports, and
+	submitted patches will require the glibc development team to allocate
+	time from an already thin time budget.  Please try to help us make
+	this time as productive as possible.  See the section below about
+	how to submit changes.
+
+
+WHO SHOULD TRY THE SNAPSHOTS
+----------------------------
+
+Remember, these are snapshots not tested versions.  So if you use
+these versions you should be able to
+
+    o	make sure your system stays usable
+
+    o	locate and hopefully fix problems
+
+    o	to port glibc to a new target yourself
+
+You should not use the snapshots if
+
+    o	your system is needed in a production environment which needs
+	stability
+
+    o	you expect us to fix your problems since you somehow depend on them.
+	You must be willing to fix the problems yourself, we don't want to
+	see "I have problems, fix this" messages.
+
+
+HOW TO GET THE SNAPSHOTS
+------------------------
+
+At the moment we provide a full snapshot weekly (every sunday), so
+that users getting a snapshot for the first time, or updating after
+a long period of not updating, can get the latest version in a single
+operation.  Along with the full snapshot, we will provide incremental
+diffs on a nearly daily basis (whenever code changes).  Each daily
+diff will be relative to the source tree after applying all previous
+daily diffs.  The daily diffs are for people who have relatively low
+bandwidth ftp or uucp connections.
+
+The files will be available via anonymous ftp from alpha.gnu.ai.mit.edu, in
+directory /gnu/libc and on linux.kernel.org in /pub/software/libs/glibc.  The
+directories should look something like:
+
+	libc-970921.tar.gz
+	libc-970917-970922.diff.gz
+	libc-970922-970925.diff.gz
+	.
+	.
+	.
+
+Please note that the snapshots on alpha.gnu.ai.mit.edu and on
+linux.kernel.org are not always in sync. Patches to some files might
+appear a day a diff earlier or later on alpha than on kernel. 
+Use always alpha or always kernel but don't mix them.
+
+There are sometimes additionally test releases of the add-ons available in
+these directories.  If a new version of an add-on is available it is normally
+required for the corresponding snapshot so always pay attention for these.
+
+Note that we provide GNU gzip compressed files only.  You can ftp gzip
+from prep.ai.mit.edu in directory pub/gnu.
+
+In some cases the dates for diffs and snapshots do not match like in the
+example above.  The full release is for 970921 but the patch is for
+970917-970922.  This only means that nothing changed between 970917 and 970922
+and that you have to use this patch on top of the 970921 snapshot since the
+patch is made on 970922.
+
+Also, as the gcc developers did with their gcc snapshot system, even though we
+will make the snapshots available on a publically accessible ftp area, we ask
+that recipients not widely publicise their availability.  The motivation for
+this request is not to hoard them, but to avoid the situation where the
+general glibc user base naively attempts to use the snapshots, has trouble with
+them, complains publically, and the reputation of glibc declines because of a
+perception of instability or lack of quality control.
+
+
+GLIBC TEST SUITE
+----------------
+
+A test suite is distributed as an integral part of the snapshots.  A simple
+"make check" in your build directory is sufficient to run the tests.  glibc
+should pass all tests and if any fails, please report it.  A failure might not
+originate from a bug in glibc but also from bugs in the tools, e.g. with gcc
+2.7.2.x the math tests fail some of the tests because of compiler bugs.
+
+Note that the test suite is still in its infancy.  The tests themselves only
+cover a small portion of libc features, and where tests do exist for a feature
+they are not exhaustive.  New tests are welcome.
+
+
+GETTING HELP, GLIBC DISCUSSIONS, etc
+------------------------------------
+
+People who want to help with glibc and who test out snapshots regularly should
+get on the libc-alpha@gnu.ai.mit.edu mailing list by sending an email to
+libc-alpha-request@gnu.ai.mit.edu.  This list is meant (as the name suggests)
+for the discussion of test releases and also reports for them.  People who are
+on this list are welcome to post questions of general interest.
+
+People who are not only willing to test the snapshots but instead really want
+to help developing glibc should contact libc-hacker-request@gnu.ai.mit.edu to
+be put on the developers mailing list.  This list is really only meant for
+developers.  No questions about installation problems or other simple topics
+are wanted nor will they be answered.
+
+Do *not* send any questions about the snapshots or patches specific to the
+snapshots to bug-glibc@prep.ai.mit.edu.  Nobody there will have any idea what
+you are talking about and it will just cause confusion.
+
+
+BUG REPORTS
+-----------
+
+Send bug reports directly to Ulrich Drepper <drepper@gnu.ai.mit.edu>.  Please
+do *not* use the glibcbug script for reporting bugs in the snapshots.
+glibcbug should only be used for problems with the official released versions.
+We don't like bug reports in the bug database because otherwise the impression
+of instability or lack of quality control of glibc as a whole might manifest
+in people's mind.
+
+Note that since no testing is done on the snapshots, and snapshots may even be
+made when glibc is in an inconsistent state, it may not be unusual for an
+occasional snapshot to have a very obvious bug, such as failure to compile on
+*any* machine.  It is likely that such bugs will be fixed by the next
+snapshot, so it really isn't necessary to report them unless they persist for
+a couple of days.
+
+Missing files should always be reported, since they usually mean there is a
+problem with the snapshot-generating process and we won't know about them
+unless someone tells us.
+
+Bugs which are non-obvious, such as failure to compile on only a specific
+machine, a new machine dependent or obscure bug (particularly one not detected
+by the testsuite), etc should be reported when you discover them, or have a
+suggested patch to fix them.
+
+
+FORMAT FOR PATCHES
+------------------
+
+If you have a fix for a bug, or an enhancement to submit, send your patch to
+Ulrich Drepper <drepper@gnu.ai.mit.edu>.  Here are some simple guidelines for
+submitting patches:
+
+    o	Use "unified diffs" for patches.  A typical command for generating
+	context diffs is "diff -ru glibc-old glibc-patched".
+
+    o	Use the "minimalist approach" for patches.  That is, each patch
+	should address only one particular bug, new feature, etc.  Do not
+	save up many unrelated changes and submit them all in one big
+	patch, since in general, the larger the patch the more difficult
+	it is for us to decide if the patch is either correct or
+	desirable.  And if we find something about the patch that needs
+	to be corrected before it can be installed, we would have to reject
+	the entire patch, which might contain changes which otherwise would
+	be accepted if submitted separately.
+
+    o	Submit a sample ChangeLog entry with your patch.  See the existing
+	glibc ChangeLog for examples of what a ChangeLog entry should look
+	like.  The emacs command ^X4A will create a ChangeLog entry header
+	for you.
+
+
+BUILDING SNAPSHOTS
+------------------
+
+The `best' way to build glibc is to use an extra directory, e.g.:
+tar xzf libc-970921.tar.gz
+mkdir build-glibc
+cd build-glibc
+../libc-970921/configure ...
+
+In this way you can easily clean up (since `make clean' doesn't work at
+the moment) and rebuild glibc.
+
+
+NECESSARY TOOLS
+---------------
+
+For the recommended versions of gcc, binutils, make, texinfo, gettext,
+autoconf and other tools which might be especially needed when using patches,
+please read the file INSTALL.
+
+
+HOW CAN YOU HELP
+----------------
+
+It helps already a lot if you just install glibc on your system and try to
+solve any problems.  You might want to look at the file `PROJECTS' and help
+with one of those projects, fix some bugs (see `BUGS' or the bug database),
+port to an unsupported platform, ...
+
+
+FURTHER DOCUMENTATION
+---------------------
+
+A lot of questions are answered in the FAQ.  The files `INSTALL', `README' and
+`NOTES' contain the most important documentation.  Furthermore glibc has its
+own 700+ pages info documentation, ...
+
+
+
+And finally a word of caution: The libc is one of the most fundamental parts
+of your system - and these snapshots are untested and come without any
+guarantee or warranty.  You might be lucky and everything works or you might
+crash your system.  If you install a glibc snapshot as primary library, you
+should have a backup somewhere.
+
+On many systems it is also a problem to replace the libc while the system is
+running.  In the worst case on broken OSes some systems crash.  On better
+systems you can move the old libc aside but removing it will cause problems
+since there are still processes using this libc image and so you might have to
+check the filesystem to get rid of the libc data.  One good alternative (which
+is also safer) is to use a chroot'ed environment.
+
+Thanks for your help and support.
+
+Thanks to Fred Fish from Cygnus for the original version of this text
+(for GDB).
+
+
+Ulrich Drepper