|Subject:||Re: libobjc2/gnustep-base also failing under FreeBSD + Debian9|
|Date:||Mon, 18 Feb 2019 17:43:01 +0100|
|Under Debian9, it is impossible to get anything properly working. It seems to be that the linker, the compiler and libobjc2 are constantly at war with each other. There is no valid combination of either of them.|
The combination which got me the furthest is the one which uses clang-7 and the standard linker.
This passes libobjc2 checks and gnustep-base checks. However once you get to your own apps, weird things will happen.
in my case I set up my AppDelegate object from main with init which in turn has a property called _runningConfig which then gets accessed like this
- (MyAppDelegate *)initWithOptions:(NSDictionary *)options
self = [super init];
/* do set up some vars */
if(_runningConfig.generalConfig.concurrentTasks!=NULL) /* IT THROWS EXCEPTION HERE */
/* read some property and do something */
I just noticed that at this point in my code _runningConfig is actually NULL because the command line parsing is done a bit later.
But the exception I get is rather puzzling:.
: Uncaught exception NSInvalidArgumentException, reason: UMLogHandler(instance) does not recognize generalConfig
how can a variable being NULL raise this exception?
and _runningConfig its not of object type UMLogHandler neither!
So obviously clang is messing up with the property offsets here. But all code have been compiled with the same compiler from A-Z !!
It also behaves like this with -O0 compiled superclass and App.
If I fix this and use self.runningConfig instead of _runningConfig, then that passes. However it then breaks at some other place with similar puzzling errors.
Above was compiled with -fobjc-runtime=gnustep-1.8 as gnustep-configure reports by default .
This is driving me nuts since more than a month now.
If anyone can solve this mystery, I'm more than happy to pay him.
|[Prev in Thread]||Current Thread||[Next in Thread]|