![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to PROBLEMS CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / contrib / emacs-18.55|
Return to PROBLEMS CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / emacs-18.55 |
1.1 ! root 1: This file describes various problems that have been encountered ! 2: in compiling, installing and running GNU Emacs. ! 3: ! 4: * Error compiling sysdep.c, "sioctl.h: no such file or directory". ! 5: ! 6: Among USG systems with TIOCGWINSZ, some require sysdep.c to include ! 7: the file sioctl.h; on others, sioctl.h does not exist. We don't know ! 8: how to distinguish these two kind of systems, so currently we try to ! 9: include sioctl.h on all of them. If this #include gets an error, just ! 10: delete it. ! 11: ! 12: * X Windows doesn't work if DISPLAY uses a hostname. ! 13: ! 14: People have reported kernel bugs in certain systems that cause Emacs ! 15: not to work with X Windows if DISPLAY is set using a host name. But ! 16: the problem does not occur if DISPLAY is set to `unix:0.0'. I think ! 17: the bug has to do with SIGIO or FIONREAD. ! 18: ! 19: You may be able to compensate for the bug by doing (set-input-mode nil nil). ! 20: However, that has the disadvantage of turning off interrupts, so that ! 21: you are unable to quit out of a Lisp program by typing C-g. ! 22: ! 23: The easy way to do this is to put ! 24: ! 25: (setq x-sigio-bug t) ! 26: ! 27: in your site-init.el file. ! 28: ! 29: * Watch out for .emacs files and EMACSLOADPATH environment vars ! 30: ! 31: These control the actions of Emacs. ! 32: ~/.emacs is your Emacs init file. ! 33: EMACSLOADPATH overrides which directories the function ! 34: "load" will search. ! 35: ! 36: If you observe strange problems, check for these and get rid ! 37: of them, then try again. ! 38: ! 39: * Fatal signal in the command temacs -l loadup inc dump ! 40: ! 41: This command is the final stage of building Emacs. It is run by the ! 42: Makefile in the src subdirectory, or by build.com on VMS. ! 43: ! 44: It has been known to get fatal errors due to insufficient swapping ! 45: space available on the machine. ! 46: ! 47: On 68000's, it has also happened because of bugs in the ! 48: subroutine `alloca'. Verify that `alloca' works right, even ! 49: for large blocks (many pages). ! 50: ! 51: * test-distrib says that the distribution has been clobbered ! 52: * or, temacs prints "Command key out of range 0-127" ! 53: * or, temacs runs and dumps xemacs, but xemacs totally fails to work. ! 54: * or, temacs gets errors dumping xemacs ! 55: ! 56: This can be because the .elc files have been garbled. Do not be ! 57: fooled by the fact that most of a .elc file is text: these are ! 58: binary files and can contain all 256 byte values. ! 59: ! 60: In particular `shar' cannot be used for transmitting GNU Emacs. ! 61: It typically truncates "lines". What appear to be "lines" in ! 62: a binary file can of course be of any length. Even once `shar' ! 63: itself is made to work correctly, `sh' discards null characters ! 64: when unpacking the shell archive. ! 65: ! 66: I have also seen character \177 changed into \377. I do not know ! 67: what transfer means caused this problem. Various network ! 68: file transfer programs are suspected of clobbering the high bit. ! 69: ! 70: The only verified ways to transfer GNU Emacs are `tar', kermit (in ! 71: binary mode on Unix), and rcp or internet ftp between two Unix systems, ! 72: or chaosnet cftp using raw mode. ! 73: ! 74: If you have a copy of Emacs that has been damaged in its ! 75: nonprinting characters, you can fix them: ! 76: ! 77: 1) Record the names of all the .elc files. ! 78: 2) Delete all the .elc files. ! 79: 3) Recompile alloc.c with a value of PURESIZE twice as large. ! 80: You might as well save the old alloc.o. ! 81: 4) Remake xemacs. It should work now. ! 82: 5) Running xemacs, do Meta-x byte-compile-file repeatedly ! 83: to recreate all the .elc files that used to exist. ! 84: You may need to increase the value of the variable ! 85: max-lisp-eval-depth to succeed in running the compiler interpreted ! 86: on certain .el files. 400 was sufficient as of last report. ! 87: 6) Reinstall the old alloc.o (undoing changes to alloc.c if any) ! 88: and remake temacs. ! 89: 7) Remake xemacs. It should work now, with valid .elc files. ! 90: ! 91: * temacs prints "Pure Lisp storage exhausted" ! 92: ! 93: This means that the Lisp code loaded from the .elc and .el ! 94: files during temacs -l loadup inc dump took up more ! 95: space than was allocated. ! 96: ! 97: This could be caused by ! 98: 1) adding code to the preloaded Lisp files ! 99: 2) adding more preloaded files in loadup.el ! 100: 3) having a site-init.el or site-load.el which loads files. ! 101: Note that ANY site-init.el or site-load.el is nonstandard; ! 102: if you have received Emacs from some other site ! 103: and it contains a site-init.el or site-load.el file, consider ! 104: deleting that file. ! 105: 4) getting the wrong .el or .elc files ! 106: (not from the directory you expected). ! 107: 5) deleting some .elc files that are supposed to exist. ! 108: This would cause the source files (.el files) to be ! 109: loaded instead. They take up more room, so you lose. ! 110: 6) a bug in the Emacs distribution which underestimates ! 111: the space required. ! 112: ! 113: If the need for more space is legitimate, change the definition ! 114: of PURESIZE in config.h. ! 115: ! 116: But in some of the cases listed above, this problem is a consequence ! 117: of something else that is wrong. Be sure to check and fix the real ! 118: problem. ! 119: ! 120: * Changes made to .el files do not take effect. ! 121: ! 122: You may have forgotten to recompile them into .elc files. ! 123: Then the old .elc files will be loaded, and your changes ! 124: will not be seen. To fix this, do M-x byte-recompile-directory ! 125: and specify the directory that contains the Lisp files. ! 126: ! 127: * The dumped Emacs (xemacs) crashes when run, trying to write pure data. ! 128: ! 129: Two causes have been seen for such problems. ! 130: ! 131: 1) On a system where getpagesize is not a system call, it is defined ! 132: as a macro. If the definition (in both unexec.c and malloc.c) is wrong, ! 133: it can cause problems like this. You might be able to find the correct ! 134: value in the man page for a.out (5). ! 135: ! 136: 2) Some systems allocate variables declared static among the ! 137: initialized variables. Emacs makes all initialized variables in most ! 138: of its files pure after dumping, but the variables declared static and ! 139: not initialized are not supposed to be pure. On these systems you ! 140: may need to add "#define static" to the m- or the s- file. ! 141: ! 142: * Compilation errors on VMS. ! 143: ! 144: You will get warnings when compiling on VMS because there are ! 145: variable names longer than 32 (or whatever it is) characters. ! 146: This is not an error. Ignore it. ! 147: ! 148: VAX C does not support #if defined(foo). Uses of this construct ! 149: were removed, but some may have crept back in. They must be rewritten. ! 150: ! 151: There is a bug in the C compiler which fails to sign extend characters ! 152: in conditional expressions. The bug is: ! 153: char c = -1, d = 1; ! 154: int i; ! 155: ! 156: i = d ? c : d; ! 157: The result is i == 255; the fix is to typecast the char in the ! 158: conditional expression as an (int). Known occurrences of such ! 159: constructs in Emacs have been fixed. ! 160: ! 161: * rmail gets error getting new mail ! 162: ! 163: rmail gets new mail from /usr/spool/mail/$USER using a program ! 164: called `movemail'. This program interlocks with /bin/mail using ! 165: the protocol defined by /bin/mail. ! 166: ! 167: There are two different protocols in general use. One of them uses ! 168: the `flock' system call. The other involves creating a lock file; ! 169: `movemail' must be able to write in /usr/spool/mail in order to do ! 170: this. You control which one is used by defining, or not defining, ! 171: the macro MAIL_USE_FLOCK in config.h or the m- or s- file it includes. ! 172: IF YOU DON'T USE THE FORM OF INTERLOCKING THAT IS NORMAL ON YOUR ! 173: SYSTEM, YOU CAN LOSE MAIL! ! 174: ! 175: If your system uses the lock file protocol, and fascist restrictions ! 176: prevent ordinary users from writing the lock files in /usr/spool/mail, ! 177: you may need to make `movemail' setgid to a suitable group such as ! 178: `mail'. ! 179: ! 180: * Emacs won't work with X-windows if the value of DISPLAY is HOSTNAME:0. ! 181: ! 182: Some people have found that Emacs was unable to connect to the local ! 183: host by name, as in DISPLAY=prep:0 if you are running on prep, but ! 184: could handle DISPLAY=unix:0. Here is what [email protected] said: ! 185: ! 186: Seems as ! 187: though gethostbyname was bombing somewhere along the way. Well, we ! 188: had just upgrade from SunOS 3.5 (which X11 was built under) to SunOS ! 189: 4.0.1. Any new X applications which tried to be built with the pre ! 190: OS-upgrade libraries had the same problems which Emacs was having. ! 191: Missing /etc/resolv.conf for a little while (when one of the libraries ! 192: was built?) also might have had a hand in it. ! 193: ! 194: The result of all of this (with some speculation) was that we rebuilt ! 195: X and then rebuilt Emacs with the new libraries. Works as it should ! 196: now. Hoorah. ! 197: ! 198: * Emacs spontaneously displays "I-search: " at the bottom of the screen. ! 199: ! 200: This means that Control-S/Control-Q "flow control" is being used. ! 201: C-s/C-q flow control is bad for Emacs editors because it takes away ! 202: C-s and C-q as user commands. Since editors do not output long streams ! 203: of text without user commands, there is no need for a user-issuable ! 204: "stop output" command in an editor; therefore, a properly designed ! 205: flow control mechanism would transmit all possible input characters ! 206: without interference. Designing such a mechanism is easy, for a person ! 207: with at least half a brain. ! 208: ! 209: There are three possible reasons why flow control could be taking place: ! 210: ! 211: 1) Terminal has not been told to disable flow control ! 212: 2) Insufficient padding for the terminal in use ! 213: 3) Some sort of terminal concentrator or line switch is responsible ! 214: ! 215: First of all, many terminals have a set-up mode which controls ! 216: whether they generate flow control characters. This must be ! 217: set to "no flow control" in order for Emacs to work. Sometimes ! 218: there is an escape sequence that the computer can send to turn ! 219: flow control off and on. If so, perhaps the termcap `ti' string ! 220: should turn flow control off, and the `te' string should turn it on. ! 221: ! 222: Once the terminal has been told "no flow control", you may find it ! 223: needs more padding. The amount of padding Emacs sends is controlled ! 224: by the termcap entry for the terminal in use, and by the output baud ! 225: rate as known by the kernel. The shell command `stty' will print ! 226: your output baud rate; `stty' with suitable arguments will set it if ! 227: it is wrong. Setting to a higher speed causes increased padding. If ! 228: the results are wrong for the correct speed, there is probably a ! 229: problem in the termcap entry. You must speak to a local Unix wizard ! 230: to fix this. Perhaps you are just using the wrong terminal type. ! 231: ! 232: For terminals that lack a "no flow control" mode, sometimes just ! 233: giving lots of padding will prevent actual generation of flow control ! 234: codes. You might as well try it. ! 235: ! 236: If you are really unlucky, your terminal is connected to the computer ! 237: through a concentrator which sends flow control to the computer, or it ! 238: insists on sending flow control itself no matter how much padding you ! 239: give it. You are screwed! You should replace the terminal or ! 240: concentrator with a properly designed one. In the mean time, ! 241: some drastic measures can make Emacs semi-work. ! 242: ! 243: One drastic measure to ignore C-s and C-q, while sending enough ! 244: padding that the terminal will not really lose any output. ! 245: Ignoring C-s and C-q can be done by using keyboard-translate-table ! 246: to map them into an undefined character such as C-^ or C-\. Sending ! 247: lots of padding is done by changing the termcap entry. Here is how ! 248: to make such a keyboard-translate-table: ! 249: ! 250: (let ((the-table (make-string 128 0))) ! 251: ;; Default is to translate each character into itself. ! 252: (let ((i 0)) ! 253: (while (< i 128) ! 254: (aset the-table i i) ! 255: (setq i (1+ i)))) ! 256: ;; Swap C-s with C-\ ! 257: (aset the-table ?\C-\\ ?\C-s) ! 258: (aset the-table ?\C-s ?\C-\\) ! 259: ;; Swap C-q with C-^ ! 260: (aset the-table ?\C-^ ?\C-q) ! 261: (aset the-table ?\C-q ?\C-^) ! 262: (setq keyboard-translate-table the-table)) ! 263: ! 264: An even more drastic measure is to make Emacs use flow control. ! 265: To do this, evaluate the Lisp expression (set-input-mode nil t). ! 266: Emacs will then interpret C-s and C-q as flow control commands. (More ! 267: precisely, it will allow the kernel to do so as it usually does.) You ! 268: will lose the ability to use them for Emacs commands. Also, as a ! 269: consequence of using CBREAK mode, the terminal's Meta-key, if any, ! 270: will not work, and C-g will be liable to cause a loss of output which ! 271: will produce garbage on the screen. (These problems apply to 4.2BSD; ! 272: they may not happen in 4.3 or VMS, and I don't know what would happen ! 273: in sysV.) You can use keyboard-translate-table, as shown above, ! 274: to map two other input characters (such as C-^ and C-\) into C-s and ! 275: C-q, so that you can still search and quote. ! 276: ! 277: I have no intention of ever redisigning the Emacs command set for ! 278: the assumption that terminals use C-s/C-q flow control. This ! 279: flow control technique is a bad design, and terminals that need ! 280: it are bad merchandise and should not be purchased. If you can ! 281: get some use out of GNU Emacs on inferior terminals, I am glad, ! 282: but I will not make Emacs worse for properly designed systems ! 283: for the sake of inferior systems. ! 284: ! 285: * Control-S and Control-Q commands are ignored completely. ! 286: ! 287: For some reason, your system is using brain-damaged C-s/C-q flow ! 288: control despite Emacs's attempts to turn it off. Perhaps your ! 289: terminal is connected to the computer through a concentrator ! 290: that wants to use flow control. ! 291: ! 292: You should first try to tell the concentrator not to use flow control. ! 293: If you succeed in this, try making the terminal work without ! 294: flow control, as described in the preceding section. ! 295: ! 296: If that line of approach is not successful, map some other characters ! 297: into C-s and C-q using keyboard-translate-table. The example above ! 298: shows how to do this with C-^ and C-\. ! 299: ! 300: * Screen is updated wrong, but only on one kind of terminal. ! 301: ! 302: This could mean that the termcap entry you are using for that ! 303: terminal is wrong, or it could mean that Emacs has a bug handing ! 304: the combination of features specified for that terminal. ! 305: ! 306: The first step in tracking this down is to record what characters ! 307: Emacs is sending to the terminal. Execute the Lisp expression ! 308: (open-termscript "./emacs-script") to make Emacs write all ! 309: terminal output into the file ~/emacs-script as well; then do ! 310: what makes the screen update wrong, and look at the file ! 311: and decode the characters using the manual for the terminal. ! 312: There are several possibilities: ! 313: ! 314: 1) The characters sent are correct, according to the terminal manual. ! 315: ! 316: In this case, there is no obvious bug in Emacs, and most likely you ! 317: need more padding, or possibly the terminal manual is wrong. ! 318: ! 319: 2) The characters sent are incorrect, due to an obscure aspect ! 320: of the terminal behavior not described in an obvious way ! 321: by termcap. ! 322: ! 323: This case is hard. It will be necessary to think of a way for ! 324: Emacs to distinguish between terminals with this kind of behavior ! 325: and other terminals that behave subtly differently but are ! 326: classified the same by termcap; or else find an algorithm for ! 327: Emacs to use that avoids the difference. Such changes must be ! 328: tested on many kinds of terminals. ! 329: ! 330: 3) The termcap entry is wrong. ! 331: ! 332: See the file etc/TERMS for information on changes ! 333: that are known to be needed in commonly used termcap entries ! 334: for certain terminals. ! 335: ! 336: 4) The characters sent are incorrect, and clearly cannot be ! 337: right for any terminal with the termcap entry you were using. ! 338: ! 339: This is unambiguously an Emacs bug, and can probably be fixed ! 340: in termcap.c, tparam.c, term.c, scroll.c, cm.c or dispnew.c. ! 341: ! 342: * Output from Control-V is slow. ! 343: ! 344: On many bit-map terminals, scrolling operations are fairly slow. ! 345: Often the termcap entry for the type of terminal in use fails ! 346: to inform Emacs of this. The two lines at the bottom of the screen ! 347: before a Control-V command are supposed to appear at the top after ! 348: the Control-V command. If Emacs thinks scrolling the lines is fast, ! 349: it will scroll them to the top of the screen. ! 350: ! 351: If scrolling is slow but Emacs thinks it is fast, the usual reason is ! 352: that the termcap entry for the terminal you are using does not ! 353: specify any padding time for the `al' and `dl' strings. Emacs ! 354: concludes that these operations take only as much time as it takes to ! 355: send the commands at whatever line speed you are using. You must ! 356: fix the termcap entry to specify, for the `al' and `dl', as much ! 357: time as the operations really take. ! 358: ! 359: Currently Emacs thinks in terms of serial lines which send characters ! 360: at a fixed rate, so that any operation which takes time for the ! 361: terminal to execute must also be padded. With bit-map terminals ! 362: operated across networks, often the network provides some sort of ! 363: flow control so that padding is never needed no matter how slow ! 364: an operation is. You must still specify a padding time if you want ! 365: Emacs to realize that the operation takes a long time. This will ! 366: cause padding characters to be sent unnecessarily, but they do ! 367: not really cost much. They will be transmitted while the scrolling ! 368: is happening and then discarded quickly by the terminal. ! 369: ! 370: Most bit-map terminals provide commands for inserting or deleting ! 371: multiple lines at once. Define the `AL' and `DL' strings in the ! 372: termcap entry to say how to do these things, and you will have ! 373: fast output without wasted padding characters. These strings should ! 374: each contain a single %-spec saying how to send the number of lines ! 375: to be scrolled. These %-specs are like those in the termcap ! 376: `cm' string. ! 377: ! 378: You should also define the `IC' and `DC' strings if your terminal ! 379: has a command to insert or delete multiple characters. These ! 380: take the number of positions to insert or delete as an argument. ! 381: ! 382: A `cs' string to set the scrolling region will reduce the amount ! 383: of motion you see on the screen when part of the screen is scrolled. ! 384: ! 385: * You type Control-H (Backspace) expecting to delete characters. ! 386: ! 387: Put `stty dec' in your .login file and your problems will disappear ! 388: after a day or two. ! 389: ! 390: The choice of Backspace for erasure was based on confusion, caused by ! 391: the fact that backspacing causes erasure (later, when you type another ! 392: character) on most display terminals. But it is a mistake. Deletion ! 393: of text is not the same thing as backspacing followed by failure to ! 394: overprint. I do not wish to propagate this confusion by conforming ! 395: to it. ! 396: ! 397: For this reason, I believe `stty dec' is the right mode to use, ! 398: and I have designed Emacs to go with that. If there were a thousand ! 399: other control characters, I would define Control-h to delete as well; ! 400: but there are not very many other control characters, and I think ! 401: that providing the most mnemonic possible Help character is more ! 402: important than adapting to people who don't use `stty dec'. ! 403: ! 404: If you are obstinate about confusing buggy overprinting with deletion, ! 405: you can redefine Backspace in your .emacs file: ! 406: (global-set-key "\b" 'delete-backward-char) ! 407: You may then wish to put the function help-command on some ! 408: other key. I leave to you the task of deciding which key. ! 409: ! 410: * Editing files through RFS gives spurious "file has changed" warnings. ! 411: It is possible that a change in Emacs 18.37 gets around this problem, ! 412: but in case not, here is a description of how to fix the RFS bug that ! 413: causes it. ! 414: ! 415: Date: Wed, 28 Jan 87 15:18:40 EST ! 416: From: Bill Sommerfeld <[email protected]> ! 417: Sender: [email protected] ! 418: To: toddb%[email protected] ! 419: Cc: bug-rfs, [email protected] ! 420: Subject: Bug in RFS server (fsync()) ! 421: ! 422: There was a serious pair of bugs in the handling of the fsync() system ! 423: call in the RFS server. ! 424: ! 425: The first is that the fsync() call is handled as another name for the ! 426: close() system call (!!). It appears that fsync() is not used by very ! 427: many programs; Emacs version 18 does an fsync() before closing files ! 428: to make sure that the bits are on the disk. ! 429: ! 430: This is fixed by the enclosed patch to the RFS server. ! 431: ! 432: The second, more serious problem, is that fsync() is treated as a ! 433: non-blocking system call (i.e., it's implemented as a message that ! 434: gets sent to the remote system without waiting for a reply). Fsync is ! 435: a useful tool for building atomic file transactions. Implementing it ! 436: as a non-blocking RPC call (when the local call blocks until the sync ! 437: is done) is a bad idea; unfortunately, changing it will break the RFS ! 438: protocol. Any suggestions? ! 439: ! 440: Bill Sommerfeld ! 441: MIT Project Athena ! 442: ! 443: (as always, your line numbers may vary) ! 444: ! 445: % rcsdiff -c -r1.2 serversyscall.c ! 446: RCS file: RCS/serversyscall.c,v ! 447: retrieving revision 1.2 ! 448: diff -c -r1.2 serversyscall.c ! 449: *** /tmp/,RCSt1003677 Wed Jan 28 15:15:02 1987 ! 450: --- serversyscall.c Wed Jan 28 15:14:48 1987 ! 451: *************** ! 452: *** 163,169 **** ! 453: /* ! 454: * No return sent for close or fsync! ! 455: */ ! 456: ! if (syscall == RSYS_close || syscall == RSYS_fsync) ! 457: proc->p_returnval = deallocate_fd(proc, msg->m_args[0]); ! 458: else ! 459: { ! 460: --- 166,172 ---- ! 461: /* ! 462: * No return sent for close or fsync! ! 463: */ ! 464: ! if (syscall == RSYS_close) ! 465: proc->p_returnval = deallocate_fd(proc, msg->m_args[0]); ! 466: else ! 467: { ! 468: ! 469: * ld complains because `alloca' is not defined on your system. ! 470: ! 471: Alloca is a library function in 4.2bsd, which is used very heavily by ! 472: GNU Emacs. Use of malloc instead is very difficult, as you would have ! 473: to arrange for the storage to be freed, and do so even in the case of ! 474: a longjmp happening inside a subroutine. Many subroutines in Emacs ! 475: can do longjmp. ! 476: ! 477: If your system does not support alloca, try defining the symbol ! 478: C_ALLOCA in the m-...h file for that machine. This will enable the use ! 479: in Emacs of a portable simulation for alloca. But you will find that ! 480: Emacs's performance and memory use improve if you write a true ! 481: alloca in assembler language. ! 482: ! 483: alloca (N) should return the address of an N-byte block of memory ! 484: added dynamically to the current stack frame. ! 485: ! 486: * Vax C compiler bugs affecting Emacs. ! 487: ! 488: You may get one of these problems compiling Emacs: ! 489: ! 490: foo.c line nnn: compiler error: no table entry for op STASG ! 491: foo.c: fatal error in /lib/ccom ! 492: ! 493: These are due to bugs in the C compiler; the code is valid C. ! 494: Unfortunately, the bugs are unpredictable: the same construct ! 495: may compile properly or trigger one of these bugs, depending ! 496: on what else is in the source file being compiled. Even changes ! 497: in header files that should not affect the file being compiled ! 498: can affect whether the bug happens. In addition, sometimes files ! 499: that compile correctly on one machine get this bug on another machine. ! 500: ! 501: As a result, it is hard for me to make sure this bug will not affect ! 502: you. I have attempted to find and alter these constructs, but more ! 503: can always appear. However, I can tell you how to deal with it if it ! 504: should happen. The bug comes from having an indexed reference to an ! 505: array of Lisp_Objects, as an argument in a function call: ! 506: Lisp_Object *args; ! 507: ... ! 508: ... foo (5, args[i], ...)... ! 509: putting the argument into a temporary variable first, as in ! 510: Lisp_Object *args; ! 511: Lisp_Object tem; ! 512: ... ! 513: tem = args[i]; ! 514: ... foo (r, tem, ...)... ! 515: causes the problem to go away. ! 516: The `contents' field of a Lisp vector is an array of Lisp_Objects, ! 517: so you may see the problem happening with indexed references to that. ! 518: ! 519: * 68000 C compiler problems ! 520: ! 521: Various 68000 compilers have different problems. ! 522: These are some that have been observed. ! 523: ! 524: ** Using value of assignment expression on union type loses. ! 525: This means that x = y = z; or foo (x = z); does not work ! 526: if x is of type Lisp_Object. ! 527: ! 528: ** "cannot reclaim" error. ! 529: ! 530: This means that an expression is too complicated. You get the correct ! 531: line number in the error message. The code must be rewritten with ! 532: simpler expressions. ! 533: ! 534: ** XCONS, XSTRING, etc macros produce incorrect code. ! 535: ! 536: If temacs fails to run at all, this may be the cause. ! 537: Compile this test program and look at the assembler code: ! 538: ! 539: struct foo { char x; unsigned int y : 24; }; ! 540: ! 541: lose (arg) ! 542: struct foo arg; ! 543: { ! 544: test ((int *) arg.y); ! 545: } ! 546: ! 547: If the code is incorrect, your compiler has this problem. ! 548: In the XCONS, etc., macros in lisp.h you must replace (a).u.val with ! 549: ((a).u.val + coercedummy) where coercedummy is declared as int. ! 550: ! 551: This problem will not happen if the m-...h file for your type ! 552: of machine defines NO_UNION_TYPE. That is the recommended setting now. ! 553: ! 554: * C compilers lose on returning unions ! 555: ! 556: I hear that some C compilers cannot handle returning ! 557: a union type. Most of the functions in GNU Emacs return ! 558: type Lisp_Object, which is currently defined as a union. ! 559: ! 560: This problem will not happen if the m-...h file for your type ! 561: of machine defines NO_UNION_TYPE. That is the recommended setting now. ! 562:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.