I'm trying to use Clang's new objc_direct_members as such:
__attribute__((objc_direct_members))
#implementation ViewController
...
#end
However, the compiler tells me warning: 'objc_direct_members' attribute isn't implemented by this Objective-C runtime. It does this regardless of whether I'm building for arm64 or x86_64. What might be the issue?
And before we get sidetracked by questions like "why would you need objc_direct_members?", I will simply say that there are numerous reasons such as smaller binary size due to less ObjC metadata.
__attribute__((objc_direct_members)) requires both, support in the compiler and support in the runtime. As the error message tells you, the runtime in the SDK of Xcode 11.4 did not have support for that in the runtime, so the compiler cannot use it as it cannot make that happen all by itself. The LLVM devs add features like this to the compiler but they are not the ones managing the Objective-C runtime, this is done by Apple and only by Apple, unless you want to use an alternative Obj-C runtime but LLVM doesn't have an own one. You cannot use Obj-C at all in clang unless your system provides a runtime for it.
I will simply say that there are numerous reasons
such as smaller binary size due to less ObjC metadata.
This is in fact rater neglectable unless your project is tiny. Reasons to use it are rather:
Way smaller call overhead (as low as calling a C function)
No exposed symbols for these methods
No way to accidentally override a "private" method (Obj-C doesn't have private methods, but you can have a method that is not exposed by the interface)
No way to call private methods
Unfortunately the last one however makes testing these methods impossible from within unit tests.
Related
I've introduced Boost.Container into my project which uses jemalloc as default allocator, looks like Boots.Container uses custom allocator which is dlmalloc and of course when linking I'm failing on "multiple definition" linkage error since two "XXXalloc" were introduced into object files. Turning the 'jemalloc' off is not an option but I cant find if it is possible to turn off the dlmalloc usage. Any idea how to solve this problem?
In reality, Boost Container is 99% header-only.
The documentation lists the DLMalloc extension as an extension: https://www.boost.org/doc/libs/1_73_0/doc/html/container/extended_allocators.html
This means you have apparently opted in to the extended allocator. If that's not what you wanted, you know what to remove.
A good hint is when you don't need to link Boost Container, as a quick inspection of the symbols exported didn't show me anything I recognize except allocator stuff.
How to check for functions which have no callers in the whole project?
I have turned these flags on: Unused Functions, Unused Values, Unused Variables in xCode, but it did not work.
Thanks a lot.
My guess is because Xcode doesn't look for Objective-C and Swift methods, Xcode looks for C functions instead.
Actually, there is no an efficient approach to do this with Xcode. You can try to find occurrences of those specific fields and methods using project find tool and comment or change access level of those fields and methods to compile errors. If you try to use one of the last one approaches, the fact of your project build successfully doesn't means you made your clean up correctly, KVC or #selector aren't detected in compile time, because it is accessed dynamically in run time.
I know AppCode have this as default and other useful tools to makes the code better.
With Objective-C, you can add iVars/properties to a class using the associated object support in the runtime.
With LLVM 2, you can now add iVars/properties to a class by declaring them in a class extension.
Is there a difference between the two? I have a feeling that LLVM just wraps the runtime support, but I'm not sure.
I believe these are two different mechanisms.
Under the fragile ABI the associated object support was the only way to extend interface, it works (I believe) at runtime by allocating additional list of associated objects.
But now with LLVM 2 you can declare ivars in class extensions, but it works only under the non-fragile ABI (try to compile that code for 32bit Leopard with fragile ABI, and you'll catch syntax errors).
Here's an article explaining how the non-fragile ABI works. It requires both the compile time and runtime support.
We have Oracle 11 running on HP-UX 11.31 and gcc 4.4.3. It seems that there is no way to link to occi, because it was built with aCC. Is there any workaround for this?
I had the silly idea that I could somehow build a library that basically proxied the connection - build the library with aCC in some way that could be linked to by gcc. Is this possible?
No, there isn't a way around that.
Different C compilers have interchangeable code using a standard ABI. You can mix and match their object code more or less with impunity.
However, different C++ compilers have a variety of different conventions that mean that their object code is not compatible. These relate to class layout (especially in multiple inheritance hierarchies and the dreaded 'diamond-of-death'), but also in name mangling conventions and exception handling. The name mangling schemes are deliberately made different so that you cannot accidentally link objects from one compiler with another.
Generally, if libraries are built using a C++ compiler, you have to link your code using the same - or at least a compatible - C++ compiler. And that almost invariably means a compiler from the same family. For example, you might be able to use G++ 4.5.0 even if the code was built with G++ 4.4.2. However, you won't be able to mix aCC with G++.
When I attempt to use SecPKCS12Import() from the Security framework as provided by Mac OS X 10.6, the result code is always errSecUnimplemented, regardless of the arguments provided.
Furthermore, the linker is unable to find symbols for the constants relevant to this function declared in SecImportExport.h (i.e. kSecImportExportPassphrase, kSecImportItemIdentity, et al.).
What on Earth is going on with this library -- is the function implemented or is it not? Why can the linker resolve all other symbols in the framework, but not these? How should I convert a PKCS12-formatted binary blob to a SecIdentityRef or SecCertificateRef and SecKeyRef pair?
What am I doing wrong? I'm sure this is a PEBKAC issue. :-)
EDIT: I see that I was very unclear in my question. I'm aware that Security.framework is implemented, given that I am able to use the other functionality it provides without an issue. Given this, I'm fairly certain that I'm linking against the framework correctly, since if I remove the link, none of the symbols can be found -- as expected. When I relink the framework, all the symbols are found, with the exception of the constants relevant to SecPKCS12Import(), e.g. kSecImportExportPassphrase, kSecImportItemIdentity, etc.
Given that I cannot use these symbols, I passed in what could have been incorrect strings (#"kSecImportItemIdentity", etc.), but the error code returned was errSecUnimplemented. This led me to believe that perhaps this specific functionality has not been implemented.
I tried using the 10.5 SDK, but that didn't work, of course. :-)
EDIT: My import is just a regular #import <Security/Security.h>. For kicks, I tried #import <Security/SecImportExport.h> as well, but this effected no change. That said, the error is issued by the linker, not the compiler.
I ran dyldinfo -export Security.framework/Security to list the symbols exported by the library and found many of the new symbols, but kSecImportExportPassphrase and friends were conspicuously missing. This might explain why the linker cannot find the symbols. The symbol for SecPKCS12Import appears in the symbol table and I can call that with no issues, it's just the functionality does not seem to be there.
Security.framework is most certainly implemented — see the Security Reference Update which documents what has changed in the framework in 10.6 and prior. Since you know the headers to use, I assume you've already consulted the Security Framework Reference.
Are you sure you're properly importing and linking against the framework? (It's in /System/Library/Security.framework, so you shouldn't have to specify the path.)
Does the compiler issue warnings or errors stating that the symbols in SecImportExport.h are undefined? (If not, how do you know they're "declared but undefined"?)
When you say that this fails on 10.6, have you tried it on an earlier version of the OS successfully?
EDIT: Okay, since you're using other parts of Security.framework successfully, and the APIs and constants you're trying to use are 10.6 only, it doesn't seem like a linking issue. What do your import look like? Are you sure you're importing SecImportExport.h properly? The constants are declared just above the SecPKCS12Import() function, so if you get warnings for the constants, you should get one for the function being undefined as well.
EDIT: I have confirmed with a member of the team at Apple that works on Security.framework that this functionality is not currently implemented. Please file a bug to gripe about this at http://bugreport.apple.com against component Security (New Bugs), version X. Include the URL to this question in your report. Sorry there's not a better answer at the moment.
To my knowledge, Apple is great at partially implementing things or leaving no documentation. If you really can't find the real implementation you need, you can use OpenSSL to extract the blobs and then Security services to import them to a keychain or further process with Security/CDSA methods. That would get you going and you can ping the Apple dev connection with further questions, if you have the possibility.
Further, looking at /System/Library/Frameworks/Security.framework/Headers/SecImportExport.h on my 10.6.2 machine, I see references to PKCS#12 in the documentation of SecKeychainItemImport()
Search that file for "PKCS12" for further information.