Re: Gorm don't work

[David Chisnall]

On 25/01/2019 12:23, Fred Kiefer wrote:
> > Am 25.01.2019 um 12:29 schrieb David Chisnall<gnustep@theravensnest.org>:
> >
> > 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 
> > @implementation).
> >
> > 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 
> Gorm.

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.

David