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.
Related
I'm adapting an (apparently outdated) Cordova plugin for use in my app (PhoneRTC if you're curious).
As a Linux/CLI guy at heart I've been struggling with XCode for a day, and I managed to iron out most of the deprecated code using a lot of Google and some blind guessing. However, now I'm stuck with a final error during the linking phase:
"Undefined symbols for architechture arm64: "_utf8_nextCharSafeBody", referenced from: [snip]"
The plugin's original installation instructions mention linking the binary to the library libicucore.dylib, but this seems to have been removed in the latest XCode (there are references of the same name with .tbh extensions available but these aren't valid for that dialog - even though I can select them, but whatever).
Some more Googling offered suggestions for linking various *.frameworks instead, but to no avail - the error remains.
Does anyone have any idea what I need to link to to make this function available? Or if it's permanently removed I'd also like to know, although that would involve rebuilding the binaries which wouldn't be something I'm looking forward to...
Or if you don't know, would there be a way to grep through Apple's libraries somehow to see which one is supposed to be defining a missing symbol?
(Needless to say, IF I can get this working it's going to be forked from the original repo and donated back to the community :))
So, I'm not sure what I changed exactly, but suddenly I could add libicucore.tbh as a linked library. I probably changed the build target or something, but in any case the linking error disappeared (to be replaced by a signing error because XCode, but that I can solve).
I'm trying to build apple's opensource libc (from http://www.opensource.apple.com/source/Libc/Libc-763.11/) on my OS X 10.6.8 laptop. This is in an attempt to essentially get a locally generated replica of /usr/lib/libSystem.B.dylib, which I intend to experiment on further.
I see a couple basic roadblocks though (unless, obviously, I'm missing something basic):
No instructions on how to do the build. There are a couple of Makefiles in the URL I reference above, but they fail to build when I try to do straightforward makes:
$make -f Makefile
Makefile:14: *** missing separator. Stop.
I suspect the source available for download is incomplete. Not incomplete in the sense that Apple isn't revealing all of the changes, but incomplete in the sense that there are source files that were (presumably) not modified by Apple, so isn't included in the collection. For example, I don't see the implementation of the "open" call (which, in the gnu libc hierarchy, is available at io/open.c)
The closest reference I could find after some googling was this: http://www.projectosx.com/forum/index.php?showtopic=1922&st=0&p=12457&#entry12457 but it still isn't close enough for my taste!
Any pointers?
Thanks!
Only some general pointers (although some links are discussing older OSX versions):
http://darwinbuild.macosforge.org/trac/ticket/6
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-projects/darwin/overlay/sys-libs/libc-darwin/libc-darwin-391.ebuild?view=markup&sortby=log
http://althenia.net/wiki/darwin#standard_library_libc
http://dev.gentoo.org/~vapier/CROSS-COMPILE-GUTS
http://www.raccoonfink.com/fink/darwin-cross/
Here's a different one from the usual confusion over duplicate symbol errors... :-)
I'm working on some legacy Mac code in an Xcode project that has the same global, "trace", defined in several different source files - for instance:
File1.c: SInt32 trace;
File2.c: Boolean trace;
etc. It's clear the original author meant them to have file-specific scope, but just neglected to prefix any of these lines with "static". That's fine, easy enough to fix.
But I'm kind of shocked the linker isn't flagging these! It looks to me like Xcode's linker (I presume gnu ld) only emits duplicate symbol warnings or errors for functions, that are linked into the code segment - but not global variables that are linked into the data segment. Instead, it silently conflates them, which is causing bugs.
So... how do I convince Xcode to emit link errors for duplicate global variables? Or get this information in some other way that can be a routine part of my build?
Well, I thought I'd answered my own question... :-)
I posted earlier:
So if you're using Xcode with LLVM GCC
4.2, go to the build settings dialog, find the "LLVM GCC 4.2 - Code
Generation" section, and check the "No
Common Blocks" checkbox. This enables
the compiler's "-fno-common" option,
and changes the object file generation
so that ld will choke and emit an
error if you have two globals in
different source files with the same
name.
Unfortunately, that doesn't seem to solve all instances. It seems to work fine if all the globals have the same type.
But the example in the question is taken straight from the code, where a variable named "trace" is defined as a global in two different files with two different types. And that's still not caught by the build system when I check that checkbox.
I have an application with a plug-in architecture that is using Boost.Threads as a DLL (specifically, a Mac OS X framework). I am trying to write a plug-in that uses Boost.Threads as well, and would like to link in the library statically. Everything builds fine but the application quickly crashes in my plug-in, deep within the Boost.Threads code. Linking to the DLL version of Boost.Threads seems to resolve the problem, but I'd like my plug-in to be self-contained.
Is it possible to have two instances of Boost.Threads with such a setup (one as a DLL, one statically linked in another DLL)? If so, what might I be missing to make the two instances get along?
Once my team faced a similar problem. For reasons I will not mention at this time, we had to develop a system that used 2 different versions of Boost (threads, system, filesystem).
The idea we came up with and executed was to grab the source code of both versions of Boost we needed, and then tweak one of them to change the symbols and function names to avoid name clashing.
In other words, we replaced all references to the name boost for bubbles inside the sources (or some other name) and also made changes to the compilation so it would build libbubbles instead of libboost.
This procedure gave us 2 sets of libraries, each with having their own binaries and header files.
If you looked at the source code of our application you would see something like:
#include <bubbles/thread.hpp>
#include <boost/thread.hpp>
bubbles::thread* thread_1;
boost::thread* thread_2;
I imagine some of the guys here already faced a similar situation. There are probably better alternatives to the one I suggested above.
I'm using Qt Creator under Mac osx, but "Follow symbol under cursor" option, to allow me to jump for class and methods' definitions, does not really work... it only works for local symbols. neither does "Switch between method declaration/definition"
Any ideas?
Thanks much for any thought.
Lior
First off, which version of Qt Creator are you using?
There is a Qt Creator 1.3 release candidate final release (1.3) out now that you might want to try: http://qt.nokia.com/developer/qt-creator-1.3-preview Qt Website Download Section :)
Hope that helps!
As #badcat said, ensure that you have the most recent version.
Other than that, when you have problems following a "symbol under cursor" it could mean 1 of 2 things.
1) I would check that you have your project appropriately constructed so that it has all the include and source files that it needs.
2) This is more rare, but check that you have function definitions in header files and that they are included properly by your source files. As opposed to what you may ask? We have a project here where, instead of include files, functions are defined in .cc files, and extern statements are used so that other files have access to them. (It's legacy code) In such a case, Qt Creator doesn't know how to find anything because files are only aware of each other while linking and have no other way to see each other.