You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
%c() has shortcomings — for instance the compiler has no idea what type it actually is and can’t do type checking on instancetype methods, forcing use of casts like this:
[(SpringBoard *)[%c(SpringBoard) sharedApplication] doThing];
((SpringBoard *)[%c(SpringBoard) sharedApplication]).isThingDone; // even worse!
Clang supports a weak_import attribute on classes that allows us to skip the linker trying to find the symbol to link, and allows the symbol to be optional just as %c() is.
Which would allow much more elegant code, like maybe:
Of course these weak symbols will be resolved at process launch time/library load time just like every other symbol dyld needs to resolve, so %c() is still necessary for late-loaded symbols.
To discuss:
Does this work on a category interface? Worst case scenario, we generate a separate file containing flags to pass the linker for weak import, or use this:
asm(".weak_reference _OBJC_CLASS_$_SpringBoard");
According to this thread the attribute method may require a linker flag anyway due to a limitation of the implementation. I’m really hoping this is a bug and that it’s fixed now, so we can use an #if directive to check the clang version and #error out if it’s a known broken version.
The text was updated successfully, but these errors were encountered:
I think I originally misunderstood the entire purpose of weak_import in the first place. From some old Apple Support forum:
iOS and OS X use a "two level namespace" for symbol binding. That means the static linker records from which dylib each undefined symbol was found. At launch time, dyld uses that info to search for that symbol only in that dylib. The use of weak_import means the symbol might be missing at runtime—but still, it must be found at build time (to record the dylib it might be in at runtime). This is different than ELF system were "weak" means the linker won't complain if no definition is found.
There are compiler flags to get around this, but they either require flags for specific symbols in question (yuck) or opting into dynamic_lookup behavior for all undefined symbols, unfortunately:
-U <symbol> where <symbol> is something like _OBJC_CLASS_$_SomeClass
-undefined dynamic_lookup which means all undefined symbols are looked up by dyld.
Because of 2., we know the functionality we want is possible; that is, dyld will happily search all images for a symbol. I've tested it. Sample code:
Note that the weak_import attribute is required; all it does is tell dyld to ignore runtime linking errors. Without it, the code will still compile, but it will crash. Anyway, compiled with clang main.m -lobjc -undefined dynamic_lookup -o foo, tested like so:
As expected, compiling without -undefined dynamic_lookup yields
Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_NSArray", referenced from:
objc-class-ref in main-97d90b.o
ld: symbol(s) not found for architecture x86_64
It is simply unfortunate that this isn't a language feature yet :/
%c()
has shortcomings — for instance the compiler has no idea what type it actually is and can’t do type checking oninstancetype
methods, forcing use of casts like this:Clang supports a
weak_import
attribute on classes that allows us to skip the linker trying to find the symbol to link, and allows the symbol to be optional just as%c()
is.Which would allow much more elegant code, like maybe:
%weakclass X
would expand to:__attribute__((weak_import)) @interface SpringBoard () @end
Of course these weak symbols will be resolved at process launch time/library load time just like every other symbol dyld needs to resolve, so
%c()
is still necessary for late-loaded symbols.To discuss:
Does this work on a category interface? Worst case scenario, we generate a separate file containing flags to pass the linker for weak import, or use this:
According to this thread the attribute method may require a linker flag anyway due to a limitation of the implementation. I’m really hoping this is a bug and that it’s fixed now, so we can use an
#if
directive to check the clang version and#error
out if it’s a known broken version.The text was updated successfully, but these errors were encountered: