-
-* Build problems on legacy systems
-
-** SunOS: Emacs gets error message from linker on Sun.
-
-If the error message says that a symbol such as `f68881_used' or
-`ffpa_used' or `start_float' is undefined, this probably indicates
-that you have compiled some libraries, such as the X libraries,
-with a floating point option other than the default.
-
-It's not terribly hard to make this work with small changes in
-crt0.c together with linking with Fcrt1.o, Wcrt1.o or Mcrt1.o.
-However, the easiest approach is to build Xlib with the default
-floating point option: -fsoft.
-
-** HPUX 10.20: Emacs crashes during dumping on the HPPA machine.
-
-This seems to be due to a GCC bug; it is fixed in GCC 2.8.1.
-
-** Vax C compiler bugs affecting Emacs.
-
-You may get one of these problems compiling Emacs:
-
- foo.c line nnn: compiler error: no table entry for op STASG
- foo.c: fatal error in /lib/ccom
-
-These are due to bugs in the C compiler; the code is valid C.
-Unfortunately, the bugs are unpredictable: the same construct
-may compile properly or trigger one of these bugs, depending
-on what else is in the source file being compiled. Even changes
-in header files that should not affect the file being compiled
-can affect whether the bug happens. In addition, sometimes files
-that compile correctly on one machine get this bug on another machine.
-
-As a result, it is hard for me to make sure this bug will not affect
-you. I have attempted to find and alter these constructs, but more
-can always appear. However, I can tell you how to deal with it if it
-should happen. The bug comes from having an indexed reference to an
-array of Lisp_Objects, as an argument in a function call:
- Lisp_Object *args;
- ...
- ... foo (5, args[i], ...)...
-putting the argument into a temporary variable first, as in
- Lisp_Object *args;
- Lisp_Object tem;
- ...
- tem = args[i];
- ... foo (r, tem, ...)...
-causes the problem to go away.
-The `contents' field of a Lisp vector is an array of Lisp_Objects,
-so you may see the problem happening with indexed references to that.
-
-** 68000 C compiler problems
-
-Various 68000 compilers have different problems.
-These are some that have been observed.
-
-*** Using value of assignment expression on union type loses.
-This means that x = y = z; or foo (x = z); does not work
-if x is of type Lisp_Object.
-
-*** "cannot reclaim" error.
-
-This means that an expression is too complicated. You get the correct
-line number in the error message. The code must be rewritten with
-simpler expressions.
-
-*** XCONS, XSTRING, etc macros produce incorrect code.
-
-If temacs fails to run at all, this may be the cause.
-Compile this test program and look at the assembler code:
-
-struct foo { char x; unsigned int y : 24; };
-
-lose (arg)
- struct foo arg;
-{
- test ((int *) arg.y);
-}
-
-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 only happen if USE_LISP_UNION_TYPE is manually
-defined in lisp.h.
-
-** C compilers lose on returning unions.
-
-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 only happen if USE_LISP_UNION_TYPE is manually
-defined in lisp.h.
-