3

I'm preparing my application for the Mac App Store and as part of that, I've dropped in Nick Paulson's NPReceiptVerification and have been trying to get things working. It's a pretty simple setup, but from what I gather you're supposed to compile libcrypto into your application as a static library to avoid compromise by way of changing out dynamic libraries.

This means that I need to provide my own libcrypto.a (if I understand correctly). I've compiled it myself and added it to my Xcode project. The problem now is that for some reason, when compiling my project Xcode just outright ignores the libcrypto in the project and instead jumps for a dylib version elsewhere on the system which lacks a 64-bit binary and thus causes the compile to fail.

What can I do to make Xcode use the compiled version of the library? I know this might seem like a simple thing, but as a hobbyist Cocoa programmer who's only worked with Apple's libraries this all seems alien.

Thank you!

John Wells
  • 1,139
  • 1
  • 10
  • 27

3 Answers3

2

I had the same issue, which I solved by renaming the .a file to 'libmycrypto.a' before adding it to the project, a solution I got from Linking to libcrypto for Leopard?. I'm guessing it may also work to change the library search path order, but I have no confidence that I won't someday mess that up again.

If you look at the link command in the output window of Xcode, you can see "-lcrypto", which changes to "-lmycrypto" when you rename and re-add the library. That prevents it from ever linking libcrypto.dylib, regardless of the order it searches for libraries.

Community
  • 1
  • 1
user2297467
  • 36
  • 2
1

I'm assuming here you're using Xcode 4, but this should be similar for Xcode 3.

Select your project in the sidebar and select your application target. Go to the Build Phases section. Under "Link Binary with Libraries", you have to make sure that your .a file is in there - not the dylib. (And also remember that there is no need to put .a files into a "Copy Files" build phase - as you will find yourself doing with Cocoa frameworks - since static libraries get compiled into your app.)

Enchilada
  • 3,859
  • 1
  • 36
  • 69
  • Thank you for your answer! Yes, I am running Xcode 4. The .a file is indeed in the Link Binary with Libraries phase, and I even removed and readded the file but the compiler still acts as if it doesn't exist at all. – John Wells Aug 13 '11 at 20:58
  • Is the dylib file also completely removed from the project, including from the "link binary with libraries" section? – Enchilada Aug 13 '11 at 21:03
  • You could also try holding down the Option key, going to the Product menu and choosing "Clean Build Folder", and compile again from scratch. Maybe it's still recording the old library into your app. – Enchilada Aug 13 '11 at 21:06
  • I've cleaned the project several times (including a build folder clean), and no trace of the dylib exists in the project anywhere. I'm really confused as to why it's still looking for it. Is there a reason that NPReceiptVerification might not be able to use a static library instead of a dynamic one? – John Wells Aug 13 '11 at 21:11
  • Hmm. I wonder what it is then. What header file are you using? Are you importing the header file from your custom compiled libcrypto? – Enchilada Aug 14 '11 at 11:57
  • I am not using any header files at the moment, wasn't aware it was necessary. In my OpenSSL source folder I have several headers… I assume it's cryptolib.h or crypto.h that I need? – John Wells Aug 14 '11 at 13:37
  • If you're using functions from the library in your source code, surely you must have imported some header files, right? What headers have you been importing? Are you maybe importing the openssl headers? If that's the case, my guess is that you also have to create your own compiled libssl.a and make sure your libssl imports the headers from your custom compiled libcrypto. Otherwise libssl will just use the libcrypto provided by the OS. – Enchilada Aug 14 '11 at 15:46
0

The problem now is that for some reason, when compiling my project Xcode just outright ignores the libcrypto in the project and instead jumps for a dylib version elsewhere on the system which lacks a 64-bit binary and thus causes the compile to fail.

Assuming your paths are correct (specifically, what you are providing via -L).... This is a known issue with Apple and Xcode. Xcode will do the same for iOS, even though iOS cannot load non-system dylibs!!! Its like Apple engineers did not get the memo...

user2297467 gave you the answer. You have to rename or move the dylib out of the library directory.

Something else that does not work in Apple's Xcode: omit -L, omit -l and specify the full path to the archive (e.g., /usr/local/ssl/libcrypto.a). This works everywhere that I am aware except Apple.

jww
  • 97,681
  • 90
  • 411
  • 885