Update.

	* sysdeps/unix/sysv/linux/configure.in: Move binutils check to...
	* sysdeps/unix/sysv/linux/mips/configure.in: ...here.  New file.

2001-05-11  Andreas Jaeger  <aj@suse.de>

1 files changed, 27 insertions, 27 deletions

diff --git a/FAQ b/FAQ
index 1a21ffd..4198a87 100644
--- a/FAQ
+++ b/FAQ
@@ -560,11 +560,11 @@ newer.
 
 1.20.	Which tools should I use for MIPS?
 
-{AJ} You should use the current development version of gcc 2.97 from CVS.
-gcc 2.95.x does not work correctly on mips-linux.
+{AJ} You should use the current development version of gcc 3.0 or newer from
+CVS.  gcc 2.95.x does not work correctly on mips-linux.
 
-You need also recent binutils, anything before and including 2.10 will not
-work correctly.  Either try the Linux binutils 2.10.0.33 from HJ Lu or the
+You need also recent binutils, anything before and including 2.11 will not
+work correctly.  Either try the Linux binutils 2.11.90.0.5 from HJ Lu or the
 current development version of binutils from CVS.
 
 Please note that `make check' might fail for a number of the math tests
@@ -1862,29 +1862,29 @@ this should be necessary.
 supports synchronous context switches only.  There are several reasons for
 this:
 
- o UNIX provides no other (portable) way of effecting a synchronous
-   context switch (also known as co-routine switch).  Some versions
-   support this via setjmp()/longjmp() but this does not work
-   universally.
-
- o As defined by the UNIX '98 standard, the only way setcontext()
-   could trigger an asychronous context switch is if this function
-   were invoked on the ucontext_t pointer passed as the third argument
-   to a signal handler.  But according to draft 5, XPG6, XBD 2.4.3,
-   setcontext() is not among the set of routines that may be called
-   from a signal handler.
-
- o If setcontext() were to be used for asynchronous context switches,
-   all kinds of synchronization and re-entrancy issues could arise and
-   these problems have already been solved by real multi-threading
-   libraries (e.g., POSIX threads or Linux threads).
-
- o Synchronous context switching can be implemented entirely in
-   user-level and less state needs to be saved/restored than for an
-   asynchronous context switch.  It is therefore useful to distinguish
-   between the two types of context switches.  Indeed, some
-   application vendors are known to use setcontext() to implement
-   co-routines on top of normal (heavier-weight) pre-emptable threads.
+- UNIX provides no other (portable) way of effecting a synchronous
+  context switch (also known as co-routine switch).  Some versions
+  support this via setjmp()/longjmp() but this does not work
+  universally.
+
+- As defined by the UNIX '98 standard, the only way setcontext()
+  could trigger an asychronous context switch is if this function
+  were invoked on the ucontext_t pointer passed as the third argument
+  to a signal handler.  But according to draft 5, XPG6, XBD 2.4.3,
+  setcontext() is not among the set of routines that may be called
+  from a signal handler.
+
+- If setcontext() were to be used for asynchronous context switches,
+  all kinds of synchronization and re-entrancy issues could arise and
+  these problems have already been solved by real multi-threading
+  libraries (e.g., POSIX threads or Linux threads).
+
+- Synchronous context switching can be implemented entirely in
+  user-level and less state needs to be saved/restored than for an
+  asynchronous context switch.  It is therefore useful to distinguish
+  between the two types of context switches.  Indeed, some
+  application vendors are known to use setcontext() to implement
+  co-routines on top of normal (heavier-weight) pre-emptable threads.
 
 It should be noted that if someone was dead-bent on using setcontext()
 on the third arg of a signal handler, then IA-64 Linux could support