> Am 25.01.2019 um 12:29 schrieb David Chisnall <[email protected]>: > > 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. Cheers Fred _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
