With the GCC ABI, each compilation unit contains a structure that
contains a pointer to other structures that contain all classes,
categories, selectors, and so on. It also contains an initialiser that
calls __objc_exec_class (in the runtime), passing this structure as an
argument.
With the GNUstep v2 ABI, each compilation unit contains categories,
selectors, and so on each in their own special section (allowing the
linker to discard them if it finds duplicates, particularly useful for
selectors). It also a function that calls __objc_load with a struct
initialised using the magic __start_{section} and __stop_{section}
symbols that the linker will fill in. Both this structure and this
function have hidden visibility (so won't be exposed after linking) and
a COMDAT (so duplicate versions linked together will be discarded). As
a result, after linking, we end up with a single .objc_load_v2 function
that calls into the runtime.
When static linking on ELF platforms, by default, no symbols from a .a
are pulled in unless they are referenced by something earlier on the
command line. A pure Objective-C .a file may not export any symbols, it
just provides some data structures for registering things with the
runtime. As such, by default, the linker will ignore it.
David
On 07/08/2019 16:07, Frederik Seiffert wrote:
Perfect, thanks – that does the trick.
Frederik
Am 07.08.2019 um 12:29 schrieb David Chisnall <[email protected]>:
Have you trued using --whole-archive?
David
On 07/08/2019 11:18, Frederik Seiffert wrote:
Hi all,
We have ObjC categories that are built into a static library, but these
categories do not get linked into the final executable.
We tried the following linker options without any success:
-fuse-ld=gold -Wl,-force_load,<path to static library>
-fuse-ld=gold -ObjC
If we define a C function in the same category and reference that, then the
categories are included.
Does anyone know if there are any linker flags we can use to fix this? This is
using the Android toolchain.
Thanks,
Frederik
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
