Re: libobjc2/gnustep-base also failing under FreeBSD + Debian9

[Andreas Fink]

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];

if(self)

{

/* 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.

On 12 Feb 2019, at 14:43, David Chisnall <theraven@theravensnest.org> wrote:

On 11/02/2019 16:10, Jordan Schidlowsky wrote:

I get these same linker errors when I link for android using a newish lld...  If you use any other linker these linker errors will go away ( gold or ld do not have these errors).

I'd be quite worried if they went away.  The linker is reporting that the compiler generated incorrect code[1].  I saw the same errors with BFD ld.  If you have a linker that is linking it without errors, I wonder what it's actually putting in the binary...

David

[1] If anyone cases: someone from Apple decided to make block descriptors public symbols with mangled names, rather than internal symbols.  This is a win most of the time, because it lets the linker deduplicate them, but unfortunately they put the Objective-C type encoding in the name.  On ELF platforms, @ is the separator between the symbol name and the symbol version, so block descriptors ended up appearing as versioned symbols.  This is now fixed in clang, to replace the @ character with something else ('\1', I think).