Emacs and LLD

[Warner Losh]

On Mon, Nov 20, 2017 at 2:39 PM, Ed Maste <emaste at freebsd.org> wrote:

> On 3 November 2017 at 11:29, Tobias Kortkamp <tobik at freebsd.org> wrote:
> >
> > My src.conf has WITH_LLD_IS_LD=yes and reading
> > https://bugs.freebsd.org/214864 leads me to believe that it's somehow
> > responsible for the problems I have with Emacs.
>
> Yes, the emacs build does some rather unusual things and it's perhaps
> not surprising that it's one of the ports that's giving grief with
> lld.
>
> The exp-run shows the same error you experienced:
>
> ./temacs --batch --load loadup bootstrap
> Fatal error 'Can't allocate initial thread' at line 337 in file
> /poudriere/jails/headamd64PR214864/usr/src/lib/libthr/thread/thr_init.c
> (errno = 12)
> gmake[2]: *** [Makefile:737: bootstrap-emacs] Abort trap (core dumped)
>
> I don't yet have any insight into the failure, and hope that someone
> with knowledge of the emacs build process and emacs internals can take
> a look.
>

Is temacs still an 'undumped' core dump[*]? Maybe the undumping code isn't
playing well with lld's different behavior than ld?

Warner

[*] For speed, emacs use to compile all its lisp, load it into a memory
arena, then take a core dump. The core dump was cleaned up so it could be
used as an executable with the now-preloaded lisp code in place. It was a
standard thing on 'big iron' that EMACS came from, but always a bit of an
'odd duck' as far as fitting into how Unix works. There used to be knobs to
do it differently for things like VMS that simply couldn't easily cope.
Maybe one of those needs to be tweaked? It's a tiny bit slower, but with
the speed of today's hardware (and most hardware made since ~2000), the
optimization likely saves time below the human threshold to detect...