On 01/07/2019 13:14, Frederik Seiffert wrote:
1. When using Qt to build a simple test app with Objective C, I’m
getting the following runtime error when launching the app:
java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol
"__start___objc_selectors" referenced by
"/data/app/org.qtproject.example.Qt_test-izIXM5mKlm3teJ8swIY-gQ==/lib/arm64/libQt-test.so"...
libQt-test here is the native library containing some basic C++ and
Objective C code. This is linked against libobjc and libgnustep-base.
What could be a reason for this symbol to be missing?
With the v2 ABI, all selectors are emitted as a symbol with hidden
visibility and a name that is a mangling of their name and type encoding
in the __objc_selectors section. The linker can then see all selectors
and deduplicate them (this is a big part of the binary size saving -
which is usually 10-20% - relative to the GCC ABI, which forced the
linker to keep a copy of every selector for every compilation unit that
referenced it. It also removes one or two instructions from the path to
load each selector).
GNU-like linkers (lld, BFD ld, gold) provide magic __start_{section} and
__stop_{section} symbol definitions for the start and end of any section
with a name that is a valid C identifier. The module initialisation
structure for the v2 ABI contains pointers to __start___objc_selectors
and __stop___objc_selectors, which the linker will fill in with the
start and end of the __objc_selectors section. This is then used by the
runtime to iterate over all of the selectors in a library.
I believe there was a bug in clang where I didn't add an empty symbol
for compilation units that didn't contain any selectors. If you then
linked a program or a library that didn't contain any selectors then
you'd see this error at link time. This should now be fixed, but you
can work around it by making sure that at least one of the
Objective-C[++] files that you link includes at least one use of a selector.
David
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
