runtime 2.0 issues.

[Andreas Fink]

Hello all,

I'm still trying to debug what breaks my install of the latest libobjc2 / gnustep-base install and found some interesting stuff while doing so.

So far it looks like libobjc2 compiles and installs properly (all tests pass) but then gnustep-base doesn't get compiled with the right option and they then lateron get into a mismatch.

Once thing I noticed is that gnustep-make applies  -fobjc-runtime=gnustep-1.8 everyhwere while it should be -fobjc-runtime=gnustep-2.0 now. If I patch this, then however ./configure of gnustep-base starts believing all kinds of nonsense and tests fails en masse. Tests which are for sure wrong such as the runtime/compiler not supporting properties or exceptions etc.

So what I did is force patched out all these options temporarely in configure.ac. Namely I had to set the following vars:

BASE_NONFRAGILE_ABI=1

OBJCSYNC=1

OBJC2RUNTIME=1

HAVE_BLOCKS=1

 Now gnustep-base compiles and installs but when running its tests, all tests are failing. So I was looking a bit more in details of why all the test programs fail.

Here is such a test case and how it's compiled:

/usr/bin/clang-7  -Wl,-rpath,/Users/afink/development/gnustep2/base/Source/./obj -rdynamic -pthread -fexceptions -fobjc-runtime=gnustep-2.0 -fblocks -o obj/basictypes ./obj/basictypes.obj/basictypes.m.o -L/Users/afink/development/gnustep2/base/Source/./obj -L/root/GNUstep/Library/Libraries -L/usr/local/lib -lgnustep-base -lpthread

/usr/bin/ld: ./obj/basictypes.obj/basictypes.m.o: undefined reference to symbol '__gnustep_objc_personality_v0'

//usr/local/lib/libobjc.so.4.6: error adding symbols: DSO missing from command line

clang: error: linker command failed with exit code 1 (use -v to see invocation)

This symbol is actually present in libobjc2:

# nm /usr/local/lib/libobjc.so.4.6 | grep gnustep

000000000022d598 d DW.ref.__gnustep_objc_personality_v0

000000000001cac0 T __gnustep_objc_personality_v0

000000000001cad0 T __gnustep_objcxx_personality_v0

0000000000023fe0 T _ZN7gnustep7libobjc19__objc_id_type_infoD0Ev

0000000000023fd0 T _ZN7gnustep7libobjc19__objc_id_type_infoD1Ev

0000000000023fd0 T _ZN7gnustep7libobjc19__objc_id_type_infoD2Ev

0000000000023fb0 T _ZN7gnustep7libobjc22__objc_class_type_infoD0Ev

0000000000023fa0 T _ZN7gnustep7libobjc22__objc_class_type_infoD1Ev

0000000000023fa0 T _ZN7gnustep7libobjc22__objc_class_type_infoD2Ev

0000000000024120 T _ZNK7gnustep7libobjc19__objc_id_type_info10__do_catchEPKSt9type_infoPPvj

0000000000024000 T _ZNK7gnustep7libobjc22__objc_class_type_info10__do_catchEPKSt9type_infoPPvj

000000000022cb90 D _ZTIN7gnustep7libobjc19__objc_id_type_infoE

000000000022cbb0 D _ZTIN7gnustep7libobjc22__objc_class_type_infoE

0000000000025b70 R _ZTSN7gnustep7libobjc19__objc_id_type_infoE

0000000000025ba0 R _ZTSN7gnustep7libobjc22__objc_class_type_infoE

000000000022cbc8 D _ZTVN7gnustep7libobjc19__objc_id_type_infoE

000000000022cc08 D _ZTVN7gnustep7libobjc22__objc_class_type_infoE

but there is no -lobjc in the command line at the end. Adding an  -lobjc  at the end of the command line seems to fix this.

it seems to be gnustep-base's configure is at fault here. gnustep-configure does in fact report including libobjc but gnustep-base doesnt care about that when doing the tests.

$ gnustep-config --objc-libs

-rdynamic -pthread -fexceptions -fobjc-runtime=gnustep-2.0 -fblocks -L/root/GNUstep/Library/Libraries -L/usr/local/lib -lpthread -lobjc -lm

The compilation of the gnustep-base tools also fail:

<compiling library>..

...

Making all for tool cvtenc...

 Linking tool cvtenc ...

./obj/cvtenc.obj/cvtenc.m.o:(.data..objc_init[.objc_init]+0x18): undefined reference to `__start___objc_classes'

./obj/cvtenc.obj/cvtenc.m.o:(.data..objc_init[.objc_init]+0x20): undefined reference to `__stop___objc_classes'

This seems to be the issue referenced in this bugreport:      https://savannah.gnu.org/bugs/?53338

if I run these test with different runtime versions, I see failures here:

# clang-7 config/config.non-fragile-ivars.m

# clang-7 -fobjc-runtime=gnustep-1.8    config/config.non-fragile-ivars.m

# clang-7 -fobjc-runtime=gnustep-1.9    config/config.non-fragile-ivars.m

# clang-7 -fobjc-runtime=gnustep-1.9.9 config/config.non-fragile-ivars.m

# clang-7 -fobjc-runtime=gnustep-2.0    config/config.non-fragile-ivars.m

/tmp/config-35c9d0.o: In function `.objcv2_load_function':

config.non-fragile-ivars.m:(.text..objcv2_load_function[.objcv2_load_function]+0xc): undefined reference to `__objc_load'

/tmp/config-35c9d0.o:(.data..objc_init[.objc_init]+0x18): undefined reference to `__start___objc_classes'

/tmp/config-35c9d0.o:(.data..objc_init[.objc_init]+0x20): undefined reference to `__stop___objc_classes'

/usr/bin/ld: a.out: hidden symbol `__stop___objc_classes' isn't defined

/usr/bin/ld: final link failed: Bad value

clang: error: linker command failed with exit code 1 (use -v to see invocation)

So now the question is, is the compiler "too old" to properly recognize -fobjc-runtime=gnustep-2.0  or is the runtime doing something wrong here?

I use clang version 7.0.1-svn348686-1~exp1~20190111074544.62 (branches/release_70) from the llvm repository.

I think this is the source of all my problems. If   passing -fobjc-runtime=gnustep-2.0 to the compiler makes so many tests fail which ./configure uses to detect things, then this causes all the nonsense lateron I'm seeing. If I pass incorrect versions, the library uses a different ABI than the application and things get even weirder.

I have an example:

I launch my binary and I see:

/usr/local/sbin/cnam-server: Uncaught exception NSInvalidArgumentException, reason: UMHTTPClient(instance) does not recognize getAdminUserNames.

this is very early in my start up code and comes from this code snippet.

@interface SS7AppDelegate : NSObject

{

    NSDictionary                *_enabledOptions;

    UMSynchronizedDictionary    *_smscSessions;

    UMCommandLine               *_commandLine;

    SchrittmacherClient         *_schrittmacherClient;

    NSString                    *_schrittmacherResourceID;

    SchrittmacherMode           _schrittmacherMode;

    UMSS7ConfigStorage          *_startupConfig;

    UMSS7ConfigStorage          *_runningConfig; /* The config storage we refer to */

    UMLogHandler                *_logHandler;

    UMLogLevel                  _logLevel;

    UMHTTPClient                *_webClient; /* The object we really get */

    /* more stuff */

}

@end

@implementation SS7AppDelegate

- (void)createInstances

{

NSArray *names;

/* make sure we have at least one default user */

names = [_runningConfig getAdminUserNames];

..

So as you can see _runningConfig is of type UMSS7ConfigStorage  but the runtime actually returns _webClient when accessing _runningConfig property. Thats why it gets an object of type UMHTTPClient which doesnt know anything about getAdminUserNames. In other words, the runtime does incorrectly calculate the offset. And that might be because it was told to use -fobjc-runtime=gnustep-1.8 when compiling gnustep-base whereas -fobjc-runtime=gnustep-2.0 is the right choice but that can't be used.

So we have a snake biting its tail here.