1

I'm using the build script from:

https://github.com/x2on/OpenSSL-for-iPhone

At this point, I'm solely interested in building the dylibs for iOS Simulator, because I'm using Delphi, for which it appears the compiler for iOS Simulator does not support static binding to the .a files.

I've "hacked" into build-libssl.sh to call:

./config shared

before the "make depend" calls, and it builds the libcrypto dylib, but not the libssl dylib.

Using the "file" command on the dylib reports that it's for i386; is there a difference in those that can be used in the simulator, or is supposed to be the same?

Dave Nottage
  • 3,411
  • 1
  • 20
  • 57

1 Answers1

0

The easiest suggestion I have for you is that instead of doing 'xcrun -sdk iphoneos ...' you should run 'xcrun -sdk iphonesimulator ...'

You might also want to check out my answer in cross compile libgcrypt static lib for use on iOS

Community
  • 1
  • 1
Jeremy Huddleston Sequoia
  • 22,938
  • 5
  • 78
  • 86
  • When I do that, including my change as above, I get at the end of the log: making install in crypto/pqueue... making install in crypto/ts... making install in crypto/srp... making install in crypto/cmac... making install in ssl... making install in engines... installing 4758cca cp: lib4758cca.dylib: No such file or directory make[1]: *** [install] Error 1 make: *** [install_sw] Error 1 – Dave Nottage Feb 14 '16 at 07:36
  • I managed to be able to make libressl compile into dylibs using your suggestion from the other SO post, thanks! However, the library I use to call into libssl and libcrypto is having issues with it, so I'd like to be able to build the dylibs from OpenSSL instead. – Dave Nottage Feb 26 '16 at 09:30
  • If you build them dynamic, you need to change their identifier to be @rpath-relative and update your linking options to setup the rpath load command appropriately in your binaries. – Jeremy Huddleston Sequoia Feb 26 '16 at 22:06
  • I don't know whether you're referring to libressl or openssl. If libressl, the dylibs load OK; it's an error at runtime causing the issue, namely: SSL3_GET_KEY_EXCHANGE:bad dh p length. If you're referring to OpenSSL, are you describing changes I need to make to the build script? – Dave Nottage Feb 26 '16 at 22:49
  • The issue I refer to about dylib ids relates to all libraries that you ship inside of a bundle. It is not specific to OpenSSL or libressl. – Jeremy Huddleston Sequoia Feb 28 '16 at 06:03
  • OK, I was just after a way of building OpenSSL as dylibs, as per my question. As I say, I successfully built and loaded the libressl dylibs; I had runtime issues. – Dave Nottage Feb 28 '16 at 19:56
  • Right, and if you are using them as dylibs, have you ensured that you have set the dylib id appropriately and setup rpath in the binary that is linking against libssl? That is very important. If you don't do that, I would certainly expect things to go wrong. It's quite possible that you have the wrong libssl.dylib loaded into your process because dyld will fallback on files in /usr/lib if it is unable to locate the correct one based on the dylib identifier, and they are not binary compatible. – Jeremy Huddleston Sequoia Feb 29 '16 at 01:00
  • I'm loading the dylibs using an explicit path. As I say, I'd rather (at this point, at least) use OpenSSL, since they've worked previously. My issue is not having worked out how to use their script to build them. – Dave Nottage Feb 29 '16 at 01:32
  • Regarding "It's quite possible that you have the wrong libssl.dylib loaded..", that's been the issue all along: they won't load anyway because they're not built for simulator. – Dave Nottage Feb 29 '16 at 01:33
  • If you followed my instructions in the linked answer, you should be able to get it to build for the simulator just fine. You will want to make sure you alter the dylib id of the resulting dylib, and setup the rpath appropriately in your executable, so it can find the dylib where you place it in the bundle. Also, my answers are not specific to libressl nor OpenSSL. You will need to do the same thing with whichever libraries you intend to use. – Jeremy Huddleston Sequoia Feb 29 '16 at 07:15
  • I followed the instructions in the linked answer. It worked for libressl, but not for OpenSSL. For OpenSSL it fails at the ./configure command, with a usage message and "pick os/compiler from:" with a long list of compilers. – Dave Nottage Feb 29 '16 at 10:38
  • Oh, that's because OpenSSL doesn't use autoconf, they have their own script. The same basic principle still holds for OpenSSL. You just need to get it to use the relevant CFLAGS to set the platform and sysroot. – Jeremy Huddleston Sequoia Mar 01 '16 at 17:51