Andrew Twyman

I thought about a shortcut for this, which would be to use the inline namespace approach, but make the inline namespace name switchable with preprocessor macro. I don't love relying...

I think that's a valid use case, and tricky to support given no standard ABI for C++. However I'd argue it's probably not the most common case. I think it's...

Name mangling doesn't guarantee uniqueness, or you'd never successfully find a symbol. What it does is make sure you get a unique symbol for every function/variable, including things like namespaces...

Yeah, the existing cmd-line arguments can ensure no conflicts between generated code by using unique prefixes. It's the support library which is at issue, since that code doesn't go through...

That will probably work for some cases. I think it only helps if the Djinni support lib and the code which uses it are in the same library. Also it...

Hmm, do Firebase and Appsee use Djinni? That's not something I'd heard of, and a bit surprising. Can you share more details of exactly which symbols are duplicated, and which...

Those don't all look like Djinni symbols to me. E.g. OAKLibUtility is an ObjC class, which could possibly be Djinni-generated, but I'm doubtful that both you and a third-party would...

Dunno, but it sounds like the problem is not related to this issue, or to Djinni in particular. Assuming that the `OAKLibUtility` class isn't defined by any 3rd-party code, the...

Depends on what symbols are duplicated, and how you build your code, so I don't think I can give specific guidance. All the symbols I see in your screenshots look...

OAKLibTest's _cppRefHandle and OAKLibUtility's _cppRefHandle aren't the same symbol. The duplication of OBJC_CLASS$_OAKLibUtility suggests to me that OAKLibUtility.m is being compiled more than once, or that it's getting compiled into...