On 25/01/2019 12:23, Fred Kiefer wrote:
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.
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
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
