What does it mean? "mixed ObjC ABI, somelibrary.a compiled without category class properties"

I presume this is coming out of the linker?

Is it new with ld_prime?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi Quinn,

is there any documentation on "category class properties" at all?

i am getting the same warning when linking a binary compiled with an (LLVM-based) compiler other than Xcode into an Xcode 15 project (and i get the reverse, when linking a Xcode 15 l,ibrary into an project with the other compiler).

Also (probably not surprising), regular category methods declared in the code compiled with the other compiler don't work when linked into the Xcode app (even when called from inide the same binary), they fail with "unknown selector" at runtime.

I am assuming someting has changed for how Categories are encoded on the binary level, but i can find zero coverage of this in the documentations for the Objective-C runtime or anywhere else. I'd very much like to be able to fix this issue with the compiler to restore comaptbility, so any pointers would be appreciated.

FWIW, this happens whetehr usig the "classic" or new defauklt linker in Xcode.

thanx, marc

this happens whetehr usig the "classic" or new defauklt linker in Xcode.

That’s important. The path forward for ld_prime issues is clear but, as this reproduces with ld64, I can’t send you down that path.

i am getting the same warning when linking a binary compiled with an (LLVM-based) compiler other than Xcode

What compiler is that?

And by “LLVM-based” do you mean:

• One based around the Clang front end?

• Or one that uses LLVM’s back end?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi Quinn,

What compiler is that?

The compiler is Elements (https://www.remobjects.com/elements). It uses LLVM as the back-end but does not use Clang, as it is not C language-based.

The path forward for ld_prime issues is clear but, as this reproduces with ld64, I can’t send you down that path.

i will double-check this to be sure.

Any assistance would be appreciated.

The fact this is tied to ld_prime is actually good news, because it gives us a clear path forward: File a bug against the new linker so that the linker team can investigate. See my posts on this thread for advice on how to file an actionable bug report.

Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Okay, i'll file a bug. take it this means there is current;ly no documentation or spec available to share for what changed with regards to how Categories work, in order to work with the current/new linker?

i'll file a bug.

Thanks.

IMPORTANT Post the bug number here when you’re done. Use a post, not a comment, so I’m notified.

take it this means …

Or perhaps the new linker should be compatible with your current code generation and the fact that this doesn’t work is a bug. It’s hard to say without in-depth knowledge about how the linker works, which I don’t have )-:

We’ll know more once the linker engineers have had a chance to look at your bug.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Done, logged as FB13353555 with a simple test acse that has the Elements linbraryu projects (and the binary, so no need to build it yourself), and a very sikmple Xcode project that uses the library and fails right away.

Or perhaps the new linker should be compatible with your current code generation and the fact that this doesn’t work is a bug. It’s hard to say without in-depth knowledge about how the linker works, which I don’t have )-: We’ll know more once the linker engineers have had a chance to look at your bug.

🤞🏼 as this is a bit of a breaking/show-stopper issue for us ;)

thanx for your assistance!

Your bug let me track down some more info about this. Let’s break it into two parts:

• What does category class properties mean?

• How does the linker handle this?

Lemme tackle each one in turn.

A while back [1] we added a new field to the Objective-C runtime’s description of a category. This field holds information about class properties. The presence of this field is indicated by a flag in the __objc_imageinfo section.

% otool -ov …/Test_QAdditions.o
…/Test_QAdditions.o:
…
Contents of (__DATA,__objc_imageinfo) section
    version 0
    flags   0x40

Note the 0x40. This is HasCategoryClassProperties, which you can see in the Darwin open source.

This flag presents a challenge to the linker because there are many input flags in the .o files and only one output flag in the Mach-O image. The linker has historically ‘played it safe’ by only setting the flag if it’s set everywhere [2]. It seems that ld_prime isn’t doing that for some reason, and we’ll use your bug (FB13353555) to investigate that.

In the meantime, you can dig into this at your end by dumping this flag for all the .o files that you’re passing to the linker and figuring out why it’s being set inconsistently. If you want to link with .o files generated by Apple compilers, that may require you to update your compiler to include this new info. However, that’s probably a good thing anyway.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] About 7-ish years, but I’ve not researched the specifics.

[2] It then also has to omit the _classProperties field. This field allows clients to determine which class methods are actually the implementation of class properties. Omitting it generally isn’t a problem. The class methods are still there though, so things work just fine unless folks are playing Silly Runtime Tricks™.

Thank you; this sounds like it's going to be very helpful and just what we needed. I'm passing it on to our compiler techs and see how it goes 🤞🏼