Re: What function sets up the GNUstep environment?

[Gustavo Tavares]

Having thought I isolated the problem—I now realize that I might actually have another issue which really shouldn't be happening.

So far—I've built the so-called "headless" config and reconfigured my "command line" app so that it launches through an NSApplicationDelegate.

This way I'm calling all the GNUstep functions as is.

The strange thing? This exception:

Throwing 0x1677ab8, in flight exception: (nil)

Exception caught by C++: 0

/root/Build/GTKApp.app/GTKApp : Uncaught exception NSInvalidArgumentException, reason: [NSMutableArray-addObject:] should be overridden by subclass

This exception gets called by `subclassResponsibility`

In theory this would be easy—I just need to fix the my NSMutableArray subclasses and fix them. The puzzle? I don't subclass NSMutableArray anywhere. Besides, the code that throws this exception in [NSObject-subclassResponsibility:(SEL)] gets the class name by executing `NSStringFromClass([self class])` so it would have given me a great clue as to where I should look and how to fix it. I also checked to see if I did a [super addObject:] anywhere which might have been something to fix. Nope—nada.

The mismatch error gets printed right after so that the full transcript looks like this:

Throwing 0x1677ab8, in flight exception: (nil)

Exception caught by C++: 0

/root/Build/GTKApp.app/GTKApp: Uncaught exception NSInvalidArgumentException, reason: [NSMutableArray-addObject:] should be overridden by subclass

GNUSTEP Internal Error:

The private GNUstep function to establish the argv and environment

variables was not called.

Mismatched library versions between GNUstep Foundation (base) and AppKit

(gui) is most often the cause of this message. Please be sure you

are using known compatible versions and not a mismatched set. Generally,

we recommend you use versions of base and gui which were released together.

For more detailed assistance, please report the error to bug-gnustep@gnu.org.

On Thu, Nov 5, 2020, at 5:40 AM, David Chisnall wrote:

On 04/11/2020 18:54, Gregory Casamento wrote:

> Just FYI, you still need a display server (whether that's X or Windows 

> or whatever) to start a headless application.  Is this an issue?  If it 

> is, then we would need something like the null backend.

I have worked around this issue in the past by running Xvnc and 

configuring the DISPLAY environment variable to look for the UNIX domain 

socket where Xvnc was listening.  Xvnc was configured to listen on a 

socket that no one had access to.

This is more overhead than a proper null back end (it's still rendering 

all of the things, its just sending them nowhere), but it's a quick hack 

that lets you run things on a headless machine.

David