discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Anyone?


From: Steven Nunez
Subject: Re: Emacs Anyone?
Date: Sun, 2 Apr 2017 02:12:43 +0000 (UTC)

Perhaps a more limited set of supported platform might be a way to start then? Having one supported platform would make a good examplar for others. FreeBSD for the *BSD group and ? for linux (I do not use Linux, so do not have a suggestion).

Also, for my understanding, is this problem specific to NetBSD and OpenBSD because of the compiler, or some other reason? I suppose one could always unset that flag manually somehow (or is that the gross hack?) after the executable is dumped. Is there a non-hack solution? If not, perhaps just declare those platform unsupported for now?

Cheers,
    - Steve


On Saturday, April 1, 2017 11:36 PM, Wolfgang Lux <wolfgang.lux@gmail.com> wrote:



> Am 25.03.2017 um 09:02 schrieb Steven Nunez <steve_nunez@yahoo.com>:
>
> Hi Guys,
>
> Just wondering if this emacs bug ever got fixed? I'm keen to dump the Gnome version that comes installed with FreeBSD and make everything I use 'native' GNUStep.
>
> Anything I can do to help, short of coding (I would if I could), but ObjC isn't something I know.

I'm afraid there's not really any trivial solution for at least NetBSD and OpenBSD that is not a gross hack. The problem is that the Objective-C runtime system expects that it's class and method tables are initialized when a program starts. In particular, for each compilation unit the compiler generates implicit calls to _objc_exec_class that makes sure the class structures and method dispatch tables are initialized for all classes used in that compilation unit. This code is added to the init section of the object file. At runtime the C startup code will execute all functions compiled into the init section. Unfortunately, in a sort of paranoia (that I generally appreciate), the NetBSD and OpenBSD startup code uses a flag in private memory to ensure that this code is executed only once. The final Emacs executable is the result of dumping the process with all essential modules loaded. Obviously, at that point the initialization code has been run and the flag is set, so when you execute the dumped emacs executable the initialization code is not run again. Now this would actually make sense if the data structures generated by the Objective-C runtime system were part of the dumped Emacs executable, but apparently they are not.


Wolfgang




reply via email to

[Prev in Thread] Current Thread [Next in Thread]