Undefined reference with gnustep-2.2 but not with gnustep-1.9 or gcc

[mcarans]

I have tried building Oolite using the supported Clang gnustep-2.2. I get just one linker error. This error does not occur when building Oolite with Clang gnustep 1.9 or gcc.

I have made a cut down example that demonstrates the issue: https://github.com/mcarans/objc_abi2.2_issue. That example builds with Clang gnustep-1.9, so the undefined reference only happens with gnustep-2.2.

The error I get (which occurs on both MinGW64 and Kubuntu) is:

/usr/bin/ld: ./obj/HelloWorld.obj/OOCache.m.o: in function `_i_OOCache_DebugGraphViz_generateGraphVizBodyWithRootNamed_':
/home/mcarans/Code/OoliteRelated/objc_abi2.2_issue/OOCache.m:1098:(.text+0xcdf): undefined reference to `__objc_ivar_offset_OOCache.cache.^{OOCacheImpl=^{OOCacheNode}^{OOCacheNode}^{OOCacheNode}I}'
clang: error: linker command failed with exit code 1 (use -v to see invocation)

It may have something to do with these C structs that are used from Objective-C:

struct OOCacheImpl
{
	// Splay tree root
	OOCacheNode				*root;
	
	// Ends of age list
	OOCacheNode				*oldest, *youngest;
	
	unsigned				count;
	NSString				*name;
};


struct OOCacheNode
{
	// Payload
	id<OOCacheComparable>	key;
	id						value;
	
	// Splay tree
	OOCacheNode				*leftChild, *rightChild;
	
	// Age list
	OOCacheNode				*younger, *older;
};

My guess is that this is a change in the way C structs are handled in different ABIs within libobjc2, so I closed the issue I had made in libs-base and opened here instead, but if it isn't related to libobjc2, then please let me know.

[davidchisnall]

Can you run nm and see if there is any symbol that starts __objc_ivar_offset_OOCache.cache?

It looks as if the method expects an ivar that is a different version of this type, missing the NSString* field at the end. Is it possible that you have two different definitions of struct OOCacheImpl visible in different compilation units?

[mcarans]

Can you run nm and see if there is any symbol that starts __objc_ivar_offset_OOCache.cache?

It looks as if the method expects an ivar that is a different version of this type, missing the NSString* field at the end. Is it possible that you have two different definitions of struct OOCacheImpl visible in different compilation units?

Thanks for your reply. Using my cut down example, I compiled (with gnustep-2.2) and then tried this:

nm *.o | grep "__objc_ivar_offset_OOCache.cache"
0000000000000000 B __objc_ivar_offset_OOCache.cache.^{OOCacheImpl=}
                 U __objc_ivar_offset_OOCache.cache.^{OOCacheImpl=^{OOCacheNode}^{OOCacheNode}^{OOCacheNode}I}

I tried the same with gnustep-1.9 and got:

nm *.o | grep "__objc_ivar_offset_OOCache.cache"
0000000000001810 D __objc_ivar_offset_OOCache.cache

Does this help?

[davidchisnall]

Hmm, that’s interesting. The ivar is emitted as a reference to an opaque type but then referenced with the complete type. That’s a slightly awkward case in the ABI and probably an ABI bug.

You can work around it by defining the struct before the ivar. In modern ObjC, the correct way to do this would be to move the private ivar definitions into the @implementation and out of the @interface.

That’s not a fix though: if this is a public ivar, the same problem would exist. I will take a look in clang and see if there’s a nice way of emitting a symbol alias for the ivar offset variable so it appears with both names.

[mcarans]

Hmm, that’s interesting. The ivar is emitted as a reference to an opaque type but then referenced with the complete type. That’s a slightly awkward case in the ABI and probably an ABI bug.

You can work around it by defining the struct before the ivar. In modern ObjC, the correct way to do this would be to move the private ivar definitions into the @implementation and out of the @interface.

That’s not a fix though: if this is a public ivar, the same problem would exist. I will take a look in clang and see if there’s a nice way of emitting a symbol alias for the ivar offset variable so it appears with both names.

@davidchisnall Thanks for suggesting moving the structs. I moved them to just below the typedefs which resolved the linker error. I then tried on Oolite as well and it linked ok.

Sadly when run, it failed with an assertion error oolite: src/Core/Entities/ShipEntity.m:14876: -[ShipEntity(SubEntityRelationship) isShipWithSubEntityShip:]: Assertion '[self isShip]' failed. and core dumped (whereas when built with with gcc or Clang gnustep-1.9, it works).

Is there a list of things to look out for when migrating from older ABIs? Maybe it is something easily fixed (like this issue).

[davidchisnall]

Can you link to the code for that assertion?

In theory, everything except @defs should work in the newer ABI, everything that doesn’t is a bug.

I think there were some changes around protocols becoming more of a real thing (needed for most of the introspection to work).

[mcarans]

@davidchisnall The assertion is here: https://github.com/OoliteProject/oolite/blob/master/src/Core/Entities/ShipEntity.m#L14876

[davidchisnall]

Hmm, I can’t quite tell what’s going on there. Where is isShip defined, and what is the receiver type?

[mcarans]

Hmm, I cat quite tell what’s going on there. Where is isShip defined, and what is the receiver type?

ShipEntity extends OOEntityWithDrawable (https://github.com/OoliteProject/oolite/blob/master/src/Core/Entities/ShipEntity.h#L192):
@interface ShipEntity: OOEntityWithDrawable <OOSubEntity, OOBeaconEntity>

OOEntityWithDrawable extends Entity (https://github.com/OoliteProject/oolite/blob/master/src/Core/Entities/OOEntityWithDrawable.h#L44):
@interface OOEntityWithDrawable: Entity

I can see in https://github.com/OoliteProject/oolite/blob/master/src/Core/Entities/Entity.h#L91:

@interface Entity: OOWeakRefObject
{
	// the base object for ships/stations/anything actually
	//////////////////////////////////////////////////////
	//
	// @public variables:
	//
	// we forego encapsulation for some variables in order to
	// lose the overheads of Obj-C accessor methods...
	//
@public
	OOUniversalID			universalID;			// used to reference the entity
	
	unsigned				isShip: 1,

and later in https://github.com/OoliteProject/oolite/blob/master/src/Core/Entities/Entity.h#L164

- (BOOL) isShip;

Then in https://github.com/OoliteProject/oolite/blob/master/src/Core/Entities/Entity.m#L131-L134:

- (BOOL)isShip
{
	return isShip;
}

Does this help?

[davidchisnall]

Hmm, that’s interesting. I wonder if we have a bug with bitfield non-fragile ivars. If you delete the : 1 then does it work? If so, that gives me a place to look.

[mcarans]

Hmm, that’s interesting. I wonder if we have a bug with bitfield non-fragile ivars. If you delete the : 1 then does it work? If so, that gives me a place to look.

Oh that fixed it on Kubuntu! Oolite started up! (Note that there are a lot of :1 elsewhere so not sure if something else will fail later but I was able to fly around).

Thanks a lot for your help to date! Hopefully this is an easy bug to fix.

[mcarans]

@davidchisnall I tried using MSYS2 MinGW64 built in libobjc2 and GNUStep libraries to build Oolite using ABI 2.2, but I got an error when running on Windows:

(I use ldd to get all the dependencies and copy them into the oolite.app folder so it is using a copy of the MSYS2 pacman installed package from /mingw64/bin)

Library versions:
mingw-w64-x86_64-gnustep-base 1.31.1-4
mingw-w64-x86_64-gnustep-make 2.9.3-1
mingw-w64-x86_64-libobjc2 2.2.1-3

Do you know what is the cause of that one or should I make a new ticket here or in libs-base?

[davidchisnall]

MinGW is a horrible mess of a mishmash of Windows and UNIX ABIs, so I try to avoid it, but it looks as if GNUstep Base was compiled against libstdc++, but the final program was not linked against it. Doing the link with gcc instead of g++ typically causes this kind of error.

Thanks for the reports, I’ll try to put together some minimal test cases and see if I can fix them in clang.