Jake Colman <jake.colman(a)xemacs.org&gt; writes: This is telling you that your version of gcc has a peculiarity in how it runs the loader and configure added '-z nocombreloc' to the linker commands. One of the recent versions (within the last year or so) of gcc and binutils made this necessary. If you search the mailing list archives for combreloc you'll probably find much of the relevant discussion. You can avoid this entire commentary by configuring with the portable dumper (--pdump) - that avoids the unexec process which causes the problems. HTH, Vin

Jake Colman <jake.colman(a)xemacs.org&gt; writes: When I searched the xemacs.org website for pdump, I found the following link: http://www.xemacs.org/Documentation/21.5/html/internals_13.html I don't know how up-to-date the information is. Some people have the (crazy, I think) idea that unexec will eventually go away. - Vin

Hrvoje Niksic <hniksic(a)xemacs.org&gt; writes: I would drop my objections to pdump if the entire thing were one file. - Vin

Hrvoje Niksic <hniksic(a)xemacs.org&gt; writes: I mean xemacs + xemacs.dmp in one file. I, too, liked Kyle's proposal - I had forgotten it until you mentioned it just now. - Vin

Michael Sperber <sperber(a)informatik.uni-tuebingen.de&gt; writes: But you don't have to initialize everything in one array. Or did I misunderstand you? Anyway, I've seen code that pulls it off, so I know it's possible in practice as well as in theory. I agree that it might be harder with something of the size of XEmacs.

Jake> Is there some benefit to the portable dumper other than the Jake> additional commentary? Yes. If you use a toolchain where the developers regularly change object layouts, or if you build for a multivariant platform, the portable dumper gives a fairly strong guarantee that (a) your build process will continue to produce a working XEmacs across those changes and (b) the same build parameters will likely work even though the hardware or parts of the toolchain change with platform variant. Almost all of the "ports" to new platforms, even with rather different hardware etc, over the last three years have been trivial: "I wonder if ./configure --pdump works? Yup. Hey, XEmacs.Org, I just built on the LOKI 7281!" So whatever the accuracy of Hrvoje's comments about "compiling to C would really be portable", the portable dumper does a good imitation. Vin, I bet you will see a day when you get a free port or an XEmacs that is usable on some platform only because of the portable dumper, while the unexec is suddenly DOA. I sure did! Thanks guys, you saved my butt! It beat ld -combreloc, which drove _four_ Linux distros crazy for about 3 months after it appeared. I never knew about it ... I was running --pdump as a matter of habit throughout, even though I was running Debian sid which got the feature as early as anybody. By the time it was being reported on the lists, GNU Emacs already had a patch, Red Hat's XEmacs maintainer got hold of it shortly thereafter, and it never really was a big issue because we had "OK, just ./configure --pdump" to fall back on in the meantime. The biggest problem was that Red Hat and SuSE had both released evil versions of the linker in which the feature defaulted on, but was undocumented in the help string. Not to mention that --pdump is the only reason we have any market share on Mac OS X at all. The native Carbon port is pretty weak, but the X port was only a few lines against vanilla 21.4. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.