I am referring to the following source: http://clpbar.sourceforge.net
Build process is the standard: ./configure followed by make
If I build on 10.5 I get a binary whose file contains: Mach-O executable i386
If I build on 10.6 I get a binary whose file contains: Mach-O 64-bit executable x86_64
How can I build from the command line on 10.6 and produce an executable of the type Mach-O executable i386, or even better a Universal binary containing executables of both types.
Please test any suggested solutions.
Thanks,
matt
By default, the version of GCC distributed with OS X 10.6 builds 64-bit binaries. The version of GCC distributed with 10.5 builds 32-bit binaries by default.
Before running ./configure, set a few environment variables. If you want it to be an Intel universal binary with i386 and x86_64 code, set the following variables (assuming you're using bash):
export CFLAGS="-arch i386 -arch x86_64"
export CXXFLAGS=$CFLAGS
export LDFLAGS=$CFLAGS
This will tell the configure script to pass these compiler and linker options, and thus build a binary with both the i386 and x86_64 architectures.
Or, if you want it to only build as an i386 binary:
export CFLAGS="-arch i386"
export CXXFLAGS=$CFLAGS
export LDFLAGS=$CFLAGS
From the Apple dev forums:
./configure CC="gcc -arch i386" CXX="g++ -arch i386"
Which works perfectly.
Use a -arch flag for each target. So, e.g.
gcc -arch i386 -arch x86_64 ...
would build a fat binary with both. I believe by default gcc builds to the target architecture, which is x86_64 with OSX 10.6.
Related
I'm trying to build Scipy from source. However, a linking step...
/usr/bin/clang -bundle -undefined dynamic_lookup -L/Users/gwg/miniconda3/envs/scipy-dev/lib -arch x86_64 -L/Users/gwg/miniconda3/envs/scipy-dev/lib -arch x86_64 -L/usr/local/opt/libomp/lib -lomp -I/usr/local/opt/libomp/include -Xpreprocessor -fopenmp -arch x86_64 build/temp.macosx-10.9-x86_64-3.7/scipy/spatial/src/distance_wrap.o -L/Users/gwg/miniconda3/envs/scipy-dev/lib/python3.7/site-packages/numpy/core/lib -Lbuild/temp.macosx-10.9-x86_64-3.7 -lnpymath -o build/lib.macosx-10.9-x86_64-3.7/scipy/spatial/_distance_wrap.cpython-37m-darwin.so
...fails, and I get the following error:
ld: in /Users/gwg/miniconda3/envs/scipy-dev/lib/python3.7/site-packages/numpy/core/lib/libnpymath.a(npy_math.o), could not parse object file /Users/gwg/miniconda3/envs/scipy-dev/lib/python3.7/site-packages/numpy/core/lib/libnpymath.a(npy_math.o): 'Unknown attribute kind (61) (Producer: 'LLVM10.0.0' Reader: 'LLVM APPLE_1_1000.10.44.4_0')', using libLTO version 'LLVM version 10.0.0, (clang-1000.10.44.4)' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I suspect it is due to the Producer: 'LLVM10.0.0' Reader: 'LLVM APPLE_1_1000.10.44.4_0' mismatch. But I don't know how to investigate this error.
Some details:
MacOS: High Sierra, 10.13.6
gcc --version:
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.10.44.4)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
clang --version:
Apple LLVM version 10.0.0 (clang-1000.10.44.4)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
I had the same issue. The suggestions here to use the conda compilers resolved the issue for me:
conda create -n scipy-dev
conda activate scipy-dev
conda config --env --add channels conda-forge
conda install numpy cython pybind11 pytest compilers openblas
python setup.py develop
It seems you're using different clang (judging from the paths like /usr/local/opt/libomp/lib). Likely the one provided by conda. In order to perform build with LTO you need to use the compatible toolchain (e.g. build everything with Apple-provided toolchain or with conda-provided one).
From the latest CS:GO update, a valve dev commented this on the reddit post:
We are upgrading the compiler toolchain we use to build CS:GO. This
pre-release branch has CS:GO built with the new toolchain. We are
releasing it as a pre-release branch to allow for testing ahead of it
being used in the next update.
There are no functional changes expected, though the new compiler
toolchain may yield a small performance boost.
Can anyone explain what a compiler toolchain is?
A tool chain is a set of tools (chain of tools) that are used to create a programmed product (runnable/executable program etc.).
Usually toolchains are used in the embedded world for cross-compiling, which means creating a program on a host which will eventually run on a different kind of target - therefore there is a need to create it with a specific compiler, linker, debugger etc.
In order to create from scratch a compiler for the target, you need to cross-compile it with a specific toolchain - that is the compiler toolchain.
So, by using the compiler toolchain you will be able to create a compiler for your target system.
A compiler toolchain is a set of tools, supporting libraries and header files that help build a program from source to an executable that can run on a machine. To see what different tools are invoked during a compilation process pass '-v' flag. e.g., gcc -v hello.c will print the following (Note comments # are mine):
$ /usr/local/Cellar/gcc/11.2.0/bin/gcc-11 -v hello.c
# Configuration options which were used to build gcc itself.
Using built-in specs.
COLLECT_GCC=/usr/local/Cellar/gcc/11.2.0/bin/gcc-11
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/11.2.0/libexec/gcc/x86_64-apple-darwin20/11.2.0/lto-wrapper
Target: x86_64-apple-darwin20
Configured with: ../configure --prefix=/usr/local/Cellar/gcc/11.2.0 --libdir=/usr/local/Cellar/gcc/11.2.0/lib/gcc/11 --disable-nls --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran,d --program-suffix=-11 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --with-zstd=/usr/local/opt/zstd --with-pkgversion='Homebrew GCC 11.2.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --enable-libphobos --build=x86_64-apple-darwin20 --with-system-zlib --disable-multilib --without-build-config --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Homebrew GCC 11.2.0)
COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=11.5.0' '-asm_macosx_version_min=11.5' '-mtune=core2' '-dumpdir' 'a-'
# Compiler invocation of cc1
/usr/local/Cellar/gcc/11.2.0/libexec/gcc/x86_64-apple-darwin20/11.2.0/cc1 -quiet -v -D__DYNAMIC__ hello.c -fPIC -quiet -dumpdir a- -dumpbase hello.c -dumpbase-ext .c -mmacosx-version-min=11.5.0 -mtune=core2 -version -o /var/folders/1n/lll3n8mj6wj975zjw804hg300000gq/T//ccfvEkdl.s
GNU C17 (Homebrew GCC 11.2.0) version 11.2.0 (x86_64-apple-darwin20)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/../../../../../../x86_64-apple-darwin20/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/include
/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/include-fixed
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks
End of search list.
GNU C17 (Homebrew GCC 11.2.0) version 11.2.0 (x86_64-apple-darwin20)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d0f2649375ab2f2193374e77e0a72e7c
COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=11.5.0' '-mtune=core2' '-dumpdir' 'a-'
# Assembler invocation
as -arch x86_64 -v -force_cpusubtype_ALL -mmacosx-version-min=11.5 -o /var/folders/1n/lll3n8mj6wj975zjw804hg300000gq/T//cc2nzxXo.o /var/folders/1n/lll3n8mj6wj975zjw804hg300000gq/T//ccfvEkdl.s
Apple clang version 12.0.5 (clang-1205.0.22.9)
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1as -triple x86_64-apple-macosx11.5.0 -filetype obj -main-file-name ccfvEkdl.s -target-cpu penryn -fdebug-compilation-dir /Users/Coolest -dwarf-debug-producer "Apple clang version 12.0.5 (clang-1205.0.22.9)" -dwarf-version=4 -mrelocation-model pic -mllvm -disable-aligned-alloc-awareness=1 -o /var/folders/1n/lll3n8mj6wj975zjw804hg300000gq/T//cc2nzxXo.o /var/folders/1n/lll3n8mj6wj975zjw804hg300000gq/T//ccfvEkdl.s
COMPILER_PATH=/usr/local/Cellar/gcc/11.2.0/libexec/gcc/x86_64-apple-darwin20/11.2.0/:/usr/local/Cellar/gcc/11.2.0/libexec/gcc/x86_64-apple-darwin20/11.2.0/:/usr/local/Cellar/gcc/11.2.0/libexec/gcc/x86_64-apple-darwin20/:/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/:/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/
LIBRARY_PATH=/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/:/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/../../../
COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=11.5.0' '-mtune=core2' '-dumpdir' 'a.'
/usr/local/Cellar/gcc/11.2.0/libexec/gcc/x86_64-apple-darwin20/11.2.0/collect2 -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/ -dynamic -arch x86_64 -macosx_version_min 11.5.0 -weak_reference_mismatches non-weak -o a.out -L/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0 -L/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/../../.. /var/folders/1n/lll3n8mj6wj975zjw804hg300000gq/T//cc2nzxXo.o -lSystem -lgcc_ext.10.5 -lgcc -lSystem -no_compact_unwind -v
collect2 version 11.2.0
# linker invocation
/usr/bin/ld -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/ -dynamic -arch x86_64 -macosx_version_min 11.5.0 -weak_reference_mismatches non-weak -o a.out -L/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0 -L/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/../../.. /var/folders/1n/lll3n8mj6wj975zjw804hg300000gq/T//cc2nzxXo.o -lSystem -lgcc_ext.10.5 -lgcc -lSystem -no_compact_unwind -v
#(#)PROGRAM:ld PROJECT:ld64-650.9
BUILD 00:19:30 Mar 17 2021
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
Library search paths:
/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0
/usr/local/Cellar/gcc/11.2.0/lib/gcc/11
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
Framework search paths:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/
Note that a compiler toolchain is necessary to build executables but it is not sufficient. What is missing from the toolchain to have ‘everything’ that is needed to build executable programs is the ‘sysroot’.
Normally when we compile a program for the same machine the compiler uses the standard headers available in ‘/usr/include‘ and libraries from ‘/usr/lib‘. These paths are hardcoded in the compiler itself so we never have to think about it. However, when building a custom compiler or when cross-compiling programs we have to tell the compiler where the sysroot is by passing a flag e.g.
gcc --sysroot="/path/to/arm64/sysroot/usr" hello.c
Most often pre-packaged cross compilers come with a script/binary that has a ‘sysroot’ path embedded into it. e.g., aarch64-linux-gnu-gcc (https://packages.ubuntu.com/xenial/devel/gcc-aarch64-linux-gnu).
First of all, I know there are similar questions but I'm having no luck, so decided to ask a new one myself.
I'm trying to brew install the 64-bit version pjsip, but I always end up with the i386 version.
I've seen people whose brew --env yields CFLAGS and CXXFLAGS, but for some reason, mine doesn't, so I have no clue where to set the correct architecture.
$ brew --env
HOMEBREW_CC: clang
HOMEBREW_CXX: clang++
MAKEFLAGS: -j2
CMAKE_PREFIX_PATH: /usr/local
CMAKE_INCLUDE_PATH: /usr/include/libxml2:/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers
CMAKE_LIBRARY_PATH: /System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries
PKG_CONFIG_LIBDIR: /usr/lib/pkgconfig:/usr/local/Library/ENV/pkgconfig/10.9
ACLOCAL_PATH: /usr/local/share/aclocal
PATH: /usr/local/Library/ENV/4.3:/usr/bin:/bin:/usr/sbin:/sbin
$ brew --config
HOMEBREW_VERSION: 0.9.5
ORIGIN: https://github.com/mxcl/homebrew
HEAD: 8c19edbdd364200fb2cc9276b0bc49ec4cb98aae
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CELLAR: /usr/local/Cellar
CPU: dual-core 64-bit penryn
OS X: 10.9-x86_64
Xcode: 5.0.1
CLT: 5.0.1.0.1.1382131676
GCC-4.0: build 5494
Clang: 5.0 build 500
X11: 2.7.4 => /opt/X11
System Ruby: 1.8.7-358
Perl: /usr/bin/perl
Python: /Library/Frameworks/Python.framework/Versions/2.7/bin/python => /Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
Ruby: /usr/bin/ruby => /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/bin/ruby
I've seen people referring to the version of ruby and I'm not sure it matters, but mine is a Universal build:
$ file /usr/bin/ruby
/usr/bin/ruby: Mach-O universal binary with 2 architectures
/usr/bin/ruby (for architecture x86_64): Mach-O 64-bit executable x86_64
/usr/bin/ruby (for architecture i386): Mach-O executable i386
brew install -v pjsip shows:
==> ./configure --prefix=/usr/local/Cellar/pjsip/2.1
checking build system type... i386-apple-darwin13.0.0
checking host system type... i386-apple-darwin13.0.0
checking target system type... i386-apple-darwin13.0.0
Somehow it thinks that we're on a 64bit system, which is odd, as I'm definitely running a 64bit OS. Checking through the arch-host-OS detection code shows that is uses arch to determine the architecture. For some odd reason, this is reporting that we're a 32bit system:
$ arch
i386
While under linux:
$ arch
x86_64
The quick solution is to do a brew edit pjsip, and change line 22 to read:
system "./configure", "--prefix=#{prefix}", "--host=x86_64-apple-darwin13.0.0", "--target=x86_64-apple-darwin13.0.0", "--host=x86_64-apple-darwin13.0.0"
then perform a brew install pjsip, and it looks like you have 64bit pjsip.
Probably fixable with an edit of the recipe to get the proper arch, rather than just passing in the --build, --host and --target options.
For one reason or another we need to create a custom 32-bit build of Perl 5.12.3 in /usr/local on Mac OS X Snow Leopard.
Can anyone explain the process or point us the direction of a tutorial or example?
On Snowleopard the kernel runs in 32bit mode and the userland mostly in 64bit mode. The kernel is able to run 32bit and 64bit userland apps without a problem.
You need to tell the perl build system to create a 32bit only binary. This is done by setting the -arch gcc flag.
For a simple singe file app you would do it like this:
gcc -arch i386 -o app app.m -lobjc -framework CoreFoundation -framework Cocoa
In your case you have to pass the arch flag to the build system.
Iam not a perl expert but i would configure perl like this:
./Configure -Dprefix=/usr/local -A ccflags="-arch i386"
If your system doesn't have 64bit kernel extensions turned on, then you should just be able to build Perl straight from source and pass DESTDIR=/usr/local on the make install command line. If the system is in 64bit mode, you'll need to look up how to cross-compile for i386, which isn't something I've had to do before as I just build perl for my native architecture, or install from a package.
Here's how I did it using Perlbrew:
Install Perlbrew
Make sure you have followed all of the proper steps including adding the bit to the end of .bash_profile.
Run the following (for perl 5.14.2, with threading. Adjust as necessary for other perl versions and options) (Thanks to WildPerl for this bit of wisdom):
perlbrew install 5.14.2 -ders -Dusethreads -Duseithreads -Accflags="-arch i386" -Accflags="-B/Developer/SDKs/MacOSX10.6.sdk/usr/include/gcc" -Accflags="-B/Developer/SDKs/MacOSX10.6.sdk/usr/lib/gcc" -Accflags="-isystem/Developer/SDKs/MacOSX10.6.sdk/usr/include" -Accflags="-F/Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks" -Accflags="-mmacosx-version-min=10.5" -Aldflags="-arch i386 -Wl,-search_paths_first" -Aldflags="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.6.sdk" -Aldflags="-mmacosx-version-min=10.5" -Alddlflags="-arch i386 -Wl,-search_paths_first" -Alddlflags="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.6.sdk" -Alddlflags="-mmacosx-version-min=10.5" -Duseshrplib
If you have a newer version of Xcode with the Developer SDKs as part of the app bundle, you'll need to create a symlink to them from /Developer:
sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/ /Developer
Install the local copy of cpanm:
perlbrew install-cpanm
After that finishes, go to the place where perlbrew installed perl (on my system that is: ~/perl5/perlbrew/perls/perl-5.14.2/lib/5.14.2/darwin-thread-multi-2level/ and edit Config.pm to change this line:
cc => 'cc',
to this:
cc => 'cc -m32',
I have a Library built in Macosx ibopencore-amrnb.a. Can I use it with my Iphone app as library? If yes How ? If not How Do i get the library working with Iphone app?
Thanks,
Sowri
Mac osX is an X86 platform the iphone uses an ARM processor so at the very least it needs to be recompiled.The architectures are very different ,though, so things like endeaness(?) and word size must be taken into consideration.
Step 1) Build the static libraries.
I've built third-party libraries, statically, for the iPhone. After a bit of trial-and-error, here's what I found to be a good starting point:
Cross-Compile for iPhoneOS:
./configure --prefix=/path/to/project/external/iphoneos/ --host="arm-apple-darwin9" --target=arm-apple-darwin9 --enable-static --disable-shared CC=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/arm-apple-darwin9-gcc-4.0.1 CFLAGS="-isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk" CPP=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/cpp
make
make install
Cross-Compile for iPhoneSimulator:
./configure --prefix=/path/to/project/external/iphonesimulator --enable-static=yes --enable-shared=no CC=/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc-4.0 CFLAGS="-arch i686 -pipe -mdynamic-no-pic -std=c99 -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wreturn-type -Wunused-variable -fmessage-length=0 -fvisibility=hidden -mmacosx-version-min=10.5 -I/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.0.sdk/usr/include/ -isysroot /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.0.sdk" CPP=/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/cpp AR=/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/ar LDFLAGS="-arch i686 -isysroot /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.0.sdk -Wl,-dead_strip -mmacosx-version-min=10.5"
make
make install
However, it's really just a starting point. It'll probably only work for projects with flexible Makefiles. If the above doesn't work, I've had to:
turn on project-specific ./configure flags
modify the configure script
modify the generated Makefile
modify autoconfigure scripts
You can also turn on optimization flags for the iPhoneOS version (after you've got it working first).
Step 2) Add the libraries to your project's search path.
In your projects Info settings, set these Build options:
Header Search Paths: "$(SRCROOT)/external/$(PLATFORM_NAME)/include"
Library Search Paths: "$(SRCROOT)/external/$(PLATFORM_NAME)/lib"
Other Linker Flags: [Add the flags for your static libs]
Afterwards, you should be able to include the third-party libraries in your project.