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: Mon, 3 Apr 2017 11:06:08 +0000 (UTC)

Interesting. I tried to compile on FreeBSD about six weeks or so ago and got:

>> ...
>> checking AppKit/AppKit.h usability... no
>> checking AppKit/AppKit.h presence... no
>> configure: error: The include files (AppKit/AppKit.h etc) that are required for a Nextstep build are missing or cannot be compiled.
>> ...
>>
>> The config line for FreeBSD 11 (zsh), with GNUStep installed from packages:
>>
>> env CFLAGS=-DGNUSTEP ./configure --with-ns --with-gnustep-conf=/usr/local/GNUstep.conf

Anyone got a working configure command for FreeBSD?

I guess there is hope after all.


On Monday, April 3, 2017 4:14 PM, Wolfgang Lux <wolfgang.lux@gmail.com> wrote:


Hi Riccardo,
>
> Wolfgang Lux wrote:
>> 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.
>
> Do you mean this makes obj-c totally non functional or it only impedes our standard initialization, but once done it would work?

The Objective-C runtime system itself is initialized properly. It's only that the Objective-C classes used in the emacs source code itself aren't initialized. If the initialization flag would be reset in the dumped executable, everything works fine. I even did this manually (checking for the offset of the flag in gdb and using a hex editor to reset that storage location) and got a fully working GNUstep Emacs on NetBSD x86. Unfortunately, since this flag is a private static variable, there is no obvious way to determine that address programmatically. One could venture a guess that the startup code's private variables are located at the beginning of the data section and modify the Emacs dumping process to copy the first few bytes (but how many exactly?) from the original program image rather than the data section of the running process, but this would be the gross hack I mentioned earlier.

>
> In any case, I repeat: this is an additional OpenBSD and NetBSD issu. On Linux I can get emacs to compile but it is not usuable anyway.

Not sure what your problems are. I've compiled emacs on Ubuntu 16.04 (i386, haven't tried x86_64) and it works as well as any other GNUstep application for me.


Wolfgang



reply via email to

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