I am playing around with otool now for hour, but I didn't figure out how to get infos, if a binary is bitcode enabled.
It tried the following:
First I build a simple iOS app and run:
otool -arch arm64 -l testApp1 | grep bitcode
After that I downloaded a binary framework from kontakt.io. I am sure that there bitcode is enabled. So I tried:
otool -arch arm64 -l KontaktSDK | grep bitcode
I also got no infos back. Do I something wrong? Is this a bug with the new Xcode8?
The reason why I play around with this is, that I have build a binary framework and I don't know why sometimes the framework is fully bitcode enabled and sometimes it isn't.
According to this answer there's two possible things to check, bitcode and __LLVM.
When I download the KontaktSDK, I can do this:
[.../KontaktSDK.framework]:;otool -arch arm64 -l KontaktSDK | grep __LLVM
segname __LLVM
segname __LLVM
Related
I have a project which needs to use Libcrypto - and I have two versions of Libcrypto (libcrypto.a (from OpenSSL 1.1.1) built for ARM64) and (lcrypto.a (from OpenSSL 1.0.2) for Intel). Leaving aside the issues of whether it's good practice or not to have two different versions, I can say that if I include libcrypto.a then I can build and run on M1 and it works fine on M1. If I include lcrypto.a then I can build and run on Intel and it works fine on Intel. What I can't do is include them both (linker error - The linked library 'lcrypto.a' is missing one or more architectures required by this target: arm64.) - and if I can't include them both then I can't build a fat binary, and my app is less than entirely useful!
My question is How can I include both in my project - or where can I get (and how can I include) a fat version of Libcrypto? I've looked at this https://github.com/balthisar/openssl-xcframeworks/releases and this https://developer.apple.com/forums/thread/670631 but I'm none the wiser. I think I built a Fat Binary - but the Fat Binary I thought that I built doesn't work for either architecture!
Use command lipo to combine binaries
Compile Intel and ARM versions separately (arm version requires Xcode 12).
export MACOSX_DEPLOYMENT_TARGET=10.9
cp -r openssl-1.1.1t openssl-1.1.1t-arm64
cp -r openssl-1.1.1t openssl-1.1.1t-x86_x64
Build the Intel half
cd openssl-1.1.1t-x86_x64
./Configure darwin64-x86_64-cc shared
make
NOTE: For openssl-1.1.1q use -Wno-error=implicit-function-declaration as a configure parameter
Build the Arm half
export MACOSX_DEPLOYMENT_TARGET=10.15 /* arm64 only with Big Sur -> minimum might be 10.16 or 11.0 */)
cd ../openssl-1.1.1t-arm64
./Configure enable-rc5 zlib darwin64-arm64-cc no-asm
make
NOTE: For openssl-1.1.1q use -Wno-error=implicit-function-declaration as a configure parameter
To create universal binary use command lipo:
cd ..
mkdir openssl-mac
lipo -create openssl-1.1.1t-arm64/libcrypto.a openssl-1.1.1t-x86_x64/libcrypto.a -output openssl-mac/libcrypto.a
lipo -create openssl-1.1.1t-arm64/libssl.a openssl-1.1.1t-x86_x64/libssl.a -output openssl-mac/libssl.a
Verify that resulting binary contains both architectures:
file libcrypto.a libssl.a
libcrypto.a: Mach-O universal binary with 2 architectures: [x86_64:current ar archive random library] [arm64]
libcrypto.a (for architecture x86_64): current ar archive random library
libcrypto.a (for architecture arm64): current ar archive random library
libssl.a: Mach-O universal binary with 2 architectures: [x86_64:current ar archive random library] [arm64]
libssl.a (for architecture x86_64): current ar archive random library
libssl.a (for architecture arm64): current ar archive random library
PS: If you plan to use dynamic library combine dylib files using lipo and run instal_name_tool
cd openssl-mac
install_name_tool -id '#rpath/libcrypto.1.1.1.dylib' libcrypto.1.1.1.dylib
install_name_tool -id '#rpath/libssl.1.1.dylib' libssl.1.1.dylib
otool -D libssl.1.1.dylib /* to verify */
Result:
libssl.1.1.dylib:
#rpath/libssl.1.1.dylib
Even though this question already has an accepted answer, I'd like to mention that I found an easier way to do this that doesn't require using lipo, just in case it helps make someone else's life easier.
The trick is to force it to compile for both architectures simultaneously.
Before calling Configure in the openssl source directory, create a file somewhere convenient (for the purposes of explaining I'll just have it in the home folder) named cc, and have it contain the following text:
#!/bin/bash
if [[ $* == *-arch\ x86_64* ]] && ! [[ $* == *-arch\ arm64* ]]; then
echo Forcing compilation with arm64
cc -arch arm64 $#
else
cc $#
fi
That script will automatically add -arch arm64 to any compilation command that only includes -arch x86_64, and leave all other compilation commands unmodified.
Give it execute permissions:
chmod a+x ~/cc
Then execute the following in your shell to force compilation with this shell script:
export CC=/Users/yourname/cc
Then proceed with configuring and building as though for arm64, but tell it to compile as x86_64:
./Configure enable-rc5 zlib no-asm darwin64-x86_64-cc
make
make install
The resulting static libs and dylibs will already be x86_64 / arm64 universal!
I have a static library that is built by other company. I want to know if it's a static library containing bitcode, which command can detect it in terminal?
As it was alread written in other answers,
otool -l yourlib.a | grep __LLVM
is the way to go.
An Apple engineer says using
otool -l yourlib.a | grep bitcode
is not reliable.
Searching for a "bitcode" section is not a reliable way to detect if your files contain embedded bitcode. If you want to do that, search for the "__LLVM" segment. You should be aware that a normal build with the -fembed-bitcode-marker option will produce minimal size embedded bitcode sections without any real content. This is done as a way of testing the bitcode-related aspects of your build without slowing down the build process. The actual bitcode content is included when you do an Archive build.
See also the comments by xCocoa.
It seems, that otool does not report the bitcode if code for the iPhone Simulator's architecture is included (x86_64 or i386).
You can list the lib's architectures with:
lipo -info yourlib.a
Then you can check for bitcode for each architecture separately, e.g:
otool -arch armv7 -l yourlib.a | grep bitcode
otool -arch arm64 -l yourlib.a | grep bitcode
It is recommended to test against LLVM symbols:
otool -l yourlib.a | grep LLVM
You should get some lines with "__LLVM"
Disclaimer: I'm the author of LibEBC.
You can use ebcutil to see whether bitcode is present in a Mach-O binary or library. You can even use it to extract the embedded bitcode from it.
https://github.com/JDevlieghere/LibEBC
And if you want to check if a specific file (yourFile.o) in the static library is bitcode enabled, you can extract the 'staticLibrary.a' and use the same otool command. However macOS doesn't allow to extract your staticLibrary.a at times with the default extract utility and most 3rd party tools doesn't work either.
You can follow these steps to check specific .o files
Get the info of the architecture
lipo -info yourStaticLibrary.a
eg output: armv7 arm64
Extract yourStaticLibrary.a for any or both of the above architecture
lipo yourStaticLibrary.a -thin armv7 -output yourStaticLibraryarmv7.a
(specify the output path you want to extract to)
You get the 'yourStaticLibraryarmv7.a' which then can be easily extracted with the default mac unarchiver
On extracting, you then get a folder 'yourStaticLibraryarmv7' containing all the .o files
otool -l yourFile.o | grep bitcode
or with the specific architecture
otool -arch armv7 -l yourFile.o | grep bitcode
If the file is bitcode enabled , you get 'sectname __bitcode' in the commandline
lipo -info lib.a // Your static library
Check architectures, select your architecture
lipo lib.a -thin arm64 -output lib_arm64.a // Extract your architecture
ar -tv lib_arm64.a // List the files
ar -xv lib_arm64.a yourfile.o // File extracted
otool -arch armm64 -l yourfile.o | grep bitcode
If the file is bitcode enabled, you get 'sectname __bitcode'
You can try:
otool -l (.o or .a file)
and look for "__bitcode" section
It was answered here:
How do I xcodebuild a static library with Bitcode enabled?
I am having trouble compiling a C library (gmp) for iOS 9 using the latest Xcode 7-beta clang. I am trying to produce bitcode to get all the warnings in Xcode to stop (and I would like to produce these libraries in bitcode). However, I can't even compile the library in the first place. ./configure fails, and after looking at the config.log, it seems ld is the problem as it is failing with "ld: library not found for -lSystem". Here is the command I have used to compile gmp in the past :
./configure CC=clang CPP="/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -E" CPPFLAGS="-isysroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/ -L /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/ -miphoneos-version-min=7.0 -arch armv7 -target arm-apple-darwin
The
-L /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/
flag I added is to see if that would help with ld finding the required libraries to link, but it fails with the same error whether I include that option or not. I have not include the option to compile into bitcode in the above command, as I I can't even get it to compile in the first place using the same command I used to use. I have noticed that when I add the gmp .a files to xcode under "link binary with libraries", that ld can't find the libraries. I must manually add the project to the ld search path in the project settings for ld to find the libraries. This wasn't necessary in Xcode 6, so is it just ld being buggy in the current beta, or is there anything I can do?
Okay, here is what worked. Set your xcode development to use the new compilers using
sudo xcode-select -s /Applications/Xcode-beta.app
Then, I used this configure :
./configure CC=clang CPP="/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -E" CPPFLAGS="-isysroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/ -fembed-bitcode -miphoneos-version-min=7.0 -arch armv7 -target arm-apple-darwin" --host=aarch64-apple-darwin --disable-assembly --enable-static --disable-shared --disable-thread-safe --enable-cxx
The above works when compiling mpfr and mpc also.
I'm trying to disassemble openSSL that I've built for iOS targeting arm64 architecture with objdump (from GNU binutil) giving it following options:
./objdump openssl -f (file headers), -t (symbol table), and -h (section headers)
but getting following error:
BFD: bfd_mach_o_scan: unknown architecture 0x100000c/0x0
objdump: ./openssl: File format not recognized
TARGET:
BFD: bfd_mach_o_scan: unknown architecture 0x100000c/0x0
The objdump -v 2.21.1 that I've built with following options:
./configure CC="gcc -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -arch i386" CXX="g++ -arch i386" -disable-werror -enable-install-libiberty -enable-targets=arm-eabi
was working fine with all arm 32-bit architectures but failed to disassemble arm64.
Does anyone know how to build objdump to allow calling:
./objdump openssl -f (file headers), -t (symbol table), and -h (section headers)
for binary that was build targeting arm64?
Thanks in advance
The objdump you're using doesn't know about the arm64 arch. 0x100000c/0x0 is the cputype (CPU_TYPE_ARM64) and cpusubtype CPU_SUBTYPE_ARM64_ALL.
Why use objdump? The otool(1) program works well and is included in the Xcode developer tools / command line tools package. The command line options are a little different but one look at the man page will make it clear how to use it.
I could successfully get code coverage information on our C++ code base on Linux using the GCC features of GCOV and the LCOV tool.
But I am having trouble in Mac OS X.
As Apple does not have the classic GCC compiler anymore, and we fear that the LLVM-GCC compiler would one day disappear too (LLVM-GCC is not even available as an option in Xcode 5.0) - we have decided to use Clang to compile our code.
While using the Clang compiler I am passing in these flags -->
-g -fprofile-arcs -ftest-coverage to generate the Code Coverage information.
I can see the .gcno files getting generated along with the object files.
When it comes to linking - "-lgcov” linker flag which works with GCC is not supported.
The code coverage on Clang / LLVM is now supported by the “profile_rt” library.
Unfortunately it’s a bit tricky to find this library because Apple for whatever reason decided not to include it in the default library path. Instead you’ll have to manually navigate to /usr/lib/ to link against it:
And as specified am linking against libprofile_rt.a library.
But i have linker issues.
But i keep getting these linker errors
Undefined symbols for architecture x86_64:
"_llvm_gcov_init", referenced from:
___llvm_gcov_init in Iso9660Reader.o
___llvm_gcov_init in AutoExtractCreator.o
___llvm_gcov_init in TempFilePath.o
___llvm_gcov_init in TempPath.o
___llvm_gcov_init in ReadDirectory.o
___llvm_gcov_init in OpenDirectory.o
___llvm_gcov_init in SpltPath.o
...
ld: symbol(s) not found for architecture x86_64
I also tried linking against the dynamic library - libprofile_rt.dylib found in
/usr/lib folder - But i still get the same issue.
This is Clang Version running on Mountain Lion.
clang --version
Apple LLVM version 5.0 (clang-500.2.75) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
I also have Xcode 5.0 and Developer Tools installed.
I solved this.
I was missing the following Linker Flags
-Wall -fprofile-arcs -ftest-coverage
Other Linker Flag -fprofile-arcs fixes the issue for me.
Build Settings > Other Linker Flags > -fprofile-arcs
The above answer did not work for me on OSX Yosemite (10.10.3) with Xcode 6.3.1. It seems that Apple moved these libraries around. I was able to get it to work with the following compile options:
-lclang_rt.profile_osx
-L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/6.1.0/lib/darwin