* bitmaps/README:

[bpt/emacs.git] / etc / PROBLEMS

diff --git a/etc/PROBLEMS b/etc/PROBLEMS
index ec96b19..1e2f482 100644 (file)
--- a/etc/PROBLEMS
+++ b/etc/PROBLEMS
@@ -1859,36 +1859,6 @@ is actually Xlib which won't work with libc.so.5.2.16.
 
 Using the old library version is a workaround.
 
-** Mac OS X
-
-*** Mac OS X (Carbon): Environment Variables from dotfiles are ignored.
-
-When starting Emacs from the Dock or the Finder on Mac OS X, the
-environment variables that are set up in dotfiles, such as .cshrc or
-.profile, are ignored.  This is because the Finder and Dock are not
-started from a shell, but instead from the Window Manager itself.
-
-The workaround for this is to create a .MacOSX/environment.plist file to
-setup these environment variables.  These environment variables will
-apply to all processes regardless of where they are started.
-For me information, see http://developer.apple.com/qa/qa2001/qa1067.html.
-
-*** Mac OS X (Carbon): Process output truncated when using ptys.
-
-There appears to be a problem with the implementation of pty's on the
-Mac OS X that causes process output to be truncated.  To avoid this,
-leave process-connection-type set to its default value of nil.
-
-*** Mac OS X 10.3.9 (Carbon): QuickTime updater breaks build.
-
-Some QuickTime updaters such as 7.0.4 and 7.2.0 are known to break
-build at the link stage with the message like "Undefined symbols:
-_HICopyAccessibilityActionDescription referenced from QuickTime
-expected to be defined in Carbon".  A workaround is to use a QuickTime
-reinstaller.  Alternatively, you can link with the frameworks in the
-corresponding SDK by specifying LDFLAGS as
-"-Wl,-F/Developer/SDKs/MacOSX10.3.0.sdk/System/Library/Frameworks".
-
 ** FreeBSD
 
 *** FreeBSD 2.1.5: useless symbolic links remain in /tmp or other
@@ -2702,7 +2672,7 @@ or
 *** Fatal signal in the command  temacs -l loadup inc dump.
 
 This command is the final stage of building Emacs.  It is run by the
-Makefile in the src subdirectory, or by build.com on VMS.
+Makefile in the src subdirectory.
 
 It has been known to get fatal errors due to insufficient swapping
 space available on the machine.
@@ -3673,25 +3643,6 @@ floating point option: -fsoft.
 
 This seems to be due to a GCC bug; it is fixed in GCC 2.8.1.
 
-** VMS: Compilation errors on VMS.
-
-You will get warnings when compiling on VMS because there are
-variable names longer than 32 (or whatever it is) characters.
-This is not an error.  Ignore it.
-
-VAX C does not support #if defined(foo).  Uses of this construct
-were removed, but some may have crept back in.  They must be rewritten.
-
-There is a bug in the C compiler which fails to sign extend characters
-in conditional expressions.  The bug is:
-       char c = -1, d = 1;
-       int i;
-
-       i = d ? c : d;
-The result is i == 255;  the fix is to typecast the char in the
-conditional expression as an (int).  Known occurrences of such
-constructs in Emacs have been fixed.
-
 ** Vax C compiler bugs affecting Emacs.
 
 You may get one of these problems compiling Emacs:
@@ -3757,8 +3708,8 @@ If the code is incorrect, your compiler has this problem.
 In the XCONS, etc., macros in lisp.h you must replace (a).u.val with
 ((a).u.val + coercedummy) where coercedummy is declared as int.
 
-This problem will not happen if the m-...h file for your type
-of machine defines NO_UNION_TYPE.  That is the recommended setting now.
+This problem will only happen if USE_LISP_UNION_TYPE is manually
+defined in lisp.h.
 
 *** C compilers lose on returning unions.
 
@@ -3766,8 +3717,8 @@ I hear that some C compilers cannot handle returning a union type.
 Most of the functions in GNU Emacs return type Lisp_Object, which is
 defined as a union on some rare architectures.
 
-This problem will not happen if the m-...h file for your type
-of machine defines NO_UNION_TYPE.
+This problem will only happen if USE_LISP_UNION_TYPE is manually
+defined in lisp.h.
 
 \f
 This file is part of GNU Emacs.