Openssl tool for mac
- OPENSSL TOOL FOR MAC INSTALL
- OPENSSL TOOL FOR MAC UPDATE
- OPENSSL TOOL FOR MAC CODE
- OPENSSL TOOL FOR MAC SERIES
What I found is that if I want to make a macOS native version of OpenSSL, I need to run the compilation from a native arm64 terminal session.
![openssl tool for mac openssl tool for mac](https://a.fsdn.com/con/app/proj/xca/screenshots/329259.jpg)
OPENSSL TOOL FOR MAC INSTALL
For convince, I made a copy of iTerm and ran it under rosetta so that I could easily install homebrew and use all those various tools, even though it wasn’t arm64 native. What I did learn, in the end, was that the terminal – being native arm64 or rosetta2 emulated x86_64 – can make a huge difference. A lot of that poking and learning the innards of how OpenSSL does its builds wasn’t entirely useful, so I won’t detail all the dead ends I attempted to follow. I grabbed OpenSSL from its source, and started poking around.
OPENSSL TOOL FOR MAC UPDATE
The vcpkg codebase grabbed this update recently, with patch, but even with this patch in place, the build was failing with the error above. The patch specifically enables a new platform code: darwin64-arm64-cc. DebuggingĪfter a number of false starts and deeper digging, I found that OpenSSL 1.1.1i included a patch that enabled arm64 macOS compilation.
OPENSSL TOOL FOR MAC CODE
Spotting LC_BUILD_VERSION and then the details following it shows the library can be linked against macOS code build for version 11.0 or later. Includes this stanza in the (copious) output: cmd LC_VERSION_MIN_IPHONEOSĪnd as far as I’ve been able to discern, if you see LC_VERSION_MIN_IPHONEOS in the output, it means the library was built for an iOS platform, and you’ll get the linker error I listed above when you try to link it to code built for macOS.Īnother library which did get compiled “correctly” shows the following stanza within its output: cmd LC_BUILD_VERSION For example, the command otool -lv ~/bin/vcpkg/installed/arm64-osx/debug/lib/libcrypto.a | grep -A5 LC_ Now this generates a lot of output, and you’re looking for some specific patterns. You can view the platform that is embedded into the library code directly using otool -lv. I found some great detail on Apple’s Developer forum in the thread at, which describes using otool, but not quite all the detail. This is a little harder to dig out, and where the command line tool otool comes into play. When the libraries are created (compiled), the libraries are also marked with information about what platform they were built for. otoolĪs I’ve learned, architecture alone isn’t sufficient for C++ code when linking the library (at least on macOS). Prior to OpenSSL version 1.1.1i, that reported an x86_64 binary. I stashed a copy of vcpkg in ~/bin on my laptop, so using the command lipo -info ~/bin/vcpkg/installed/arm64-osx/lib/libcrypto.a reports the following: Non-fat file: /Users/heckj/bin/vcpkg/installed/arm64-osx/lib/libcrypto.a is architecture: arm64 The command lipo -info /path/to/library.a, tells you the architecture for that library. Lipo does a number of things – mostly around merging various archives into fat libraries, but the key part I’ve been using it for is to determine what architecture a library was built to support.
![openssl tool for mac openssl tool for mac](https://phoenixnap.com/kb/wp-content/uploads/2021/04/how-ssl-certificates-work.png)
Ld: in /Users/heckj/bin/vcpkg/installed/arm64-osx/debug/lib/libcrypto.a(a_strex.o), building for macOS, but linking in object file built for iOSįor anyone else hitting this sort of thing, there’s two macOS specific command-line tools that you should know about to investigate this kind of thing: lipo and otool. The part that hasn’t been so smooth is there’s an odd complication with vcpkg, openssl, and the M1 Macs that ends up with a linker error when the build system tries to integrate and link the binaries created and managed by vcpkg. Both vcpkg and openssl recently had updates to resolve compilation issues with M1/arm based Macs, most of which revolved around a (common) built-in assumption that macOS meant you were building for an x86_64 architecture, or maybe, just maybe, cross-compiling for iOS.
OPENSSL TOOL FOR MAC SERIES
With the M1 series of laptops available from Apple, we wanted to compile and use this same code as an M1 arm64 native binary. One of the dependencies that this project uses is grpc, which in turn has a transitive dependency on OpenSSL. It happens to align well with this project, which uses CMake as its build system. It has a number of C++ library dependencies, which it’s managing with vcpkg, a fairly nice library package manager solution for C++ projects. I’m working on a private C++ language based project, previously written to be cross platform (Windows, Linux, and Mac). Let me provide the backdrop for this story: This article isn’t a how-to so much as a debugging/dev diary entry for future-me, and any other soul who stumbles into the same (or similar) issues.