[Top][All Lists]

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

Re: Gorm don't work

From: David Chisnall
Subject: Re: Gorm don't work
Date: Fri, 25 Jan 2019 12:47:12 +0000
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

On 25/01/2019 12:23, Fred Kiefer wrote:
Am 25.01.2019 um 12:29 schrieb David Chisnall<address@hidden>:

On 22/01/2019 22:15, Germán Arias wrote:
2019-01-22 16:01:48.065 Gorm[5259:5259] GormDocument.m:109  Assertion
failed in GormDocument(instance), method _docWindow.  Unable to find
_window ivar in NSDocument class
This looks like it's in the code I changed for compatibility with the new ABI.  
Gorm is now using reflection to find private ivars in GNUstep, rather than 
accessing them directly (accessing private ivars in the new ABI will now cause 
a link failure anywhere other than the compilation unit containing the 

If this assertion fails, it means that the Objective-C compiler / runtime that 
you are using is not able to find reflection metadata for the _window ivar in 
NSDocument.  This is quite worrying, because looking up ivars via the 
reflection APIs worked even back in the GCC 3.x days.
It is a lot easier than that. You just made a small mistake and used an 
NSString here instead of a C String. Of course this cannot work, with neither 
of the compilers. Which just shows that nobody did recompile and use Gorm after 
your change.
I fixed this in git and this specific issue should be gone now. There are a lot 
of other compiler warnings I get when compiling Gorm and there is also the 
runtime warning about _popUpItemAction:, but that should not block the usage of 

I did recompile it (and have a FreeBSD package of it built from the git version including my change installed), but I missed the compiler warning in a sea of other ones. This is why -Werror is a good idea.

I ran Gorm to test, but apparently managed not to trigger this code path.


reply via email to

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