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.
Related
I want to compile the following project that's hosted on GitHub. I'm on MacOs High Sierra 10.13.5.
When I run make on the solver directory, it gives the following error after running gcc with the -static option:
g++ -o dapcstp src/bbnode.o src/bbtree.o src/bounds.o src/cputime.o
src/heur.o src/inst.o src/main.o src/options.o src/prep.o
src/procstatus.o src/sol.o src/stats.o src/timer.o src/util.o -static -
lboost_timer -lboost_system -lboost_chrono -lboost_program_options -
lboost_filesystem
ld: library not found for -lcrt0.o
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make: *** [dapcstp] Error 1
In the answer to ld: library not found for -lcrt0.o on OSX 10.6 with gcc/clang -static flag it says the following:
This option will not work on Mac OS X unless all libraries (including libgcc.a) have also been compiled with -static. Since neither a static version of libSystem.dylib nor crt0.o are provided, this option is not useful to most people.
Is there a way I could circumvent this limitation and compile the project correctly on Mac ?
Looking at the project, the -static option is superfluous and counterproductive (even on system where static linking is supported). You can just remove it.
When compiling cocos2d-js for AppleTV project I receive this error:
ld: '/Users/pepa/Library/Developer/Xcode/DerivedData/GameXY-gwkkxwmtiilmalhdxfdjgqdfhedy/Build/Products/Debug-appletvos/libcocos2d
tvOS.a(bio_lib.o)' does not contain bitcode. You must rebuild it with
bitcode enabled (Xcode setting ENABLE_BITCODE) or obtain an updated
library from the vendor for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I believe that I've included only libs built for AppleTV target with bitcode enabled. But the compiler is still complaining. Is the hint to tell which library miss the bitcode in the brackets? (bio_lib.o)
If so, would you know which library it belongs to? I did not find it on my computer.
I'm using the prebuilt binaries from here: https://github.com/elvman/cocos2d-x-3rd-party-libs-bin/tree/tvos
Use next steps:
Install git, make, autoconf, automake, libtool. If you are using Homebrew this can be done by:
brew install git make autoconf automake libtool
Clone repository:
git clone https://github.com/cocos2d/cocos2d-x-3rd-party-libs-src.git
Go to cocos2d-x-3rd-party-libs-src/build and change 2 lines in file tvos.ini:
cfg_build_release_mode="-O3 -DNDEBUG -fembed-bitcode"
cfg_build_debug_mode="-O0 -g -DDEBUG -fembed-bitcode"
Run build script:
build.sh -p=tvos --libs=curl --arch=arm64,x86_64 --mode=release
update libcurl.a crypto and ssl library
Ok for anyone coming here trying to build cocos2d-x (3.10) for iOS using Bitcode enabled. I did it, based on the answer of user1675169 ( https://stackoverflow.com/a/33969215/129202 ) but of course I replaced the os in the build.sh line, and I had to replace all of these one by one:
libtiff.a
libwebp.a
libchipmunk.a
libjpeg.a
libpng.a
libfreetype.a
It took me a while to replace each and everyone of these. Depending on what you use in your cocos2d-x project, you might need to replace other libraries as well. Probably in the end cocos2d-x 3.11 will be delivered with all of these libraries recompiled with bitcode enabled in the first place.
A recompile line could look like this:
build.sh -p=ios --libs=tiff --arch=arm64,x86_64 --mode=release
In the end I was able to precompile the whole libcocos2d with bitcode enabled. I haven't tried sending this to iTunes Connect yet but I guess it might actually work in the end.
Can you (reasonably) get Fedora 21 to where it only has llvm/clang/libc++/libc++abi? (I found some things suggesting no, but they were all about 3 years old, and llvm/clang has come a long way since then.)
With a fresh install, I tried
yum install gcc gcc-c++
(downloaded, built, installed llvm/cfe(clang)/compiler-rt/libcxx/libcxxabi from svn)
yum remove gcc gcc-c++
added to /etc/profile: export CC=/usr/local/bin/clang \ export CXX=/usr/local/bin/clang++
(in case of hard wiring)
ln -s /usr/local/bin/clang /usr/local/bin/gcc
ln -s /usr/local/bin/clang /usr/local/bin/cc
ln -s /usr/local/bin/clang++ /usr/local/bin/g++
ln -s /usr/local/bin/clang++ /usr/local/bin/c++
ldconfig
I was all happy, then went to build something, and I got:
ld: cannot find crtbegin.o
ld: cannot find -lgcc
ld: cannot find -lgcc_s
clang -v includes
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.9.2
ldconfig && ldconfig -p | grep libgcc does show
libgcc_s.so.1 (libc6,x86-64) => /lib64/libgcc_s.so.1
And /lib64 is a symlink to /usr/lib64. And, /usr/lib64/libgcc_s.so.1 is a symlink to /usr/lib64/libgcc_s-4.9.2-20150212.so.1, which exists as a real file (92816 bytes.)
So, I don't get what ld's problem is on -lgcc_s. crtbegin is nowhere to be found, and gcc (no _s) is nowhere to be found.
yum install libgcc says it's already installed and latest version, nothing to do.
Since I have an installed clang source build, can I re-build clang, this time using clang rather than gcc, to get rid of the dependency? (Maybe then the "candidate GCC installation" bit goes away.)
Can I force -stdlib=c++ and -lc++abi to be default, or at least have libc++ and libc++abi installed without gcc?
Having spent some time trying to get clang to work with libc++ and libc++abi without GCC, I have found that it is indeed possible, even if a bit problematic given the current state of LLVM/clang. In addition to small test programs, I've been able to build CMake and some other software packages written in C++ with no GCC installed, and with the resulting binaries being independent of libstdc++; they only depend on libc++/libc++abi according to ldd output. Unfortunately, I haven't been able to build clang itself with clang that was build using GCC. I've been experimenting on different Linux platforms (Fedora 21 32-bit, Amazon Linux release 2015.3 (RPM-based) 64-bit, CentOS 7.1 64-bit, and Ubuntu 14.04 64-bit).
Even though one can build software with clang using libc++/libc++abi without dependency on libstdc++ and without GCC compiler present, a typical Linux installation is so tied to libgcc and libstdc++ that getting rid of these is not practical. Try removing these two packages and you will see how much of the system depends on them. Even on FreeBSD 10.1, with clang being the default compiler and no GCC installed, libgcc.a, libgcc_s.so, and a few crt*.o files are used when building a program as revealed by the -v option. Also, on FreeBSD 10.1, resulting binaries depend on libgcc according to ldd. On Ubuntu, which has dpkg as the package manager, the files
libgcc.a
libgcc_s.so
crtbegin.o
crtbeginT.o
crtbeginS.o
crtendS.o
crtend.o
are in the libgcc-devel package, while on an RPM-based system, such as Fedora, these are in the gcc package. In addition, you might possibly need these files, even though I didn't need them for the code I tried building:
crtfastmath.o
crtprec32.o
crtprec80.o
crtprec64.o
Thus one might argue that the aforementioned files better belong in libgcc, rather than in gcc. As far as I can tell, the following needs to be done on an RPM-based system before removing the gcc package:
1) Create the symlink
libgcc_s.so -> libgcc_s.so.1
in whatever directory libgcc_s.so.1 is located.
2) Copy the crt*.o files listed above to that directory.
3) In the same directory create the symlink (libstdc++.so.x should already be there; x is a number):
libstdc++.so -> libstdc++.so.x
You only need this if you are going to use libstdc++; this isn't needed if you only plan to use libc++. On some
systems libstdc++.so, which is a symlink to libstdc++.so.x belonging to the libstdc++ package, is placed by the libstdc++-devel package into the GCC library directory, so you can remove that directory after uninstalling GCC and just create the symlink in the same directory where libstdc++.so.x lives.
Now you should be able to do the following:
1) Build a C program:
clang progname.c
2) Build a C++ program using libstdc++ headers/libs:
clang++ -I<location of headers> progname.cpp
On RPM-based systems I've looked at, the libstdc++ headers are part of the libstdc++-devel package and their location can be found from rpm -ql on the package.
3) Build a C++ program using libc++ headers/libs:
clang++ -I/<location of headers> progname.cpp -nodefaultlibs -lc++ -lc++abi -lm -lc -lgcc -lgcc_s
The location of the headers is wherever they were installed when you built LLVM+clang etc.
Please see http://libcxx.llvm.org/ for additional information. When building C++ code using libc++/libc++abi, you may use -stdlib=libc++ instead of the -I flag, but in my testing that only worked with clang built from source, not with clang installed from a repository (you can install clang from repo and use it to build libc++/libc++abi; or you can use gcc to build libc++(abi), then remove gcc and use the libs with the repo-provided clang).
When configuring a software package to build it using clang + libc++, you might need to set the following:
LIBS="-nodefaultlibs -lc++ -lc++abi -lm -lc -lgcc_s -lgcc"
CXX=clang++
CXXFLAGS="-stdlib=libc++"
CC=clang
Please note that to configure CMake source in order to build it I had to use a wrapper script like this:
#!/bin/bash
MYLFLAGS="-nodefaultlibs -lc++ -lc++abi -lm -lc -lgcc_s -lgcc"
# Catch the case when we only want to compile; this helps us avoid some warnings:
if echo "$#" | egrep "(^-c | -c | -c$)" >/dev/null 2>&1; then
MYLFLAGS=""
fi
/usr/local/bin/clang++ -stdlib=libc++ "$#" $MYLFLAGS
It might be useful for other purposes as well.
For more information please see my article at http://www.omniprog.info/clang_no_gcc.html
The issue I'm having is that gcc (and family) don't appear to be properly setup. I have a 10.7.4 machine that I just installed Xcode on (from the app store). I've done no prior development on this machine.
Working w/in Xcode seems to work fine. I can build and compile no problem. However, trying to execute gcc command line fails.
First, I gcc wasn't on my path ... no big deal. I located it and ran as:
/Applications/Xcode.app/Contents/Developer/usr/bin/gcc -dynamiclib -fno-common -o s.dylib s.c
(I'm working on a lib w/some functions...). Anyways, it fails.
s.c:1:19: error: stdio.h: No such file or directory
s.c:2:20: error: stdlib.h: No such file or directory
s.c:3:20: error: string.h: No such file or directory
Surprise! hah, well I searched my machine for stdio.h and I can't find it anywhere. Since I've been out of the OSX game for a bit, I'm assuming I'm missing something -
Basically I want to be able to continue using Xcode but I want to be able to build C/C++/etc on the command line with all the dependencies (.h) in the correct place.
Any thoughts?
There are two main ways to run the compiler from the command line: the Command Line Tools package, and xcrun.
xcrun is particularly good if you just need this occasionally. Just stick "xcrun" at the start, like you'd do with sudo:
xcrun gcc -dynamiclib -fno-common -o s.dylib s.c
This will find the correct version of gcc and set the needed directories, etc. You can specify a specific SDK with --sdk.
If you do this a lot, download and install the Command Line Tools package (Xcode>Open Developer Tool>More Tools...; it also may be available in Preferences>Downloads). This installs a full copy of everything in /usr.
Probably xcrun is not enough if you are using 10.8.
Looking in to the clang documentation I found that you need to include the system root because you do not have your libraries in the standard place but inside Xcode.
using:
xcrun gcc -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
or:
xcrun clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
I want to have a static Universal binary lib of Boost. (Preferable the latest stable version, that is 1.43.0, or newer.)
I found many Google hits with similar problems and possible solutions. However, most of them seems outdated. Also none of them really worked.
Right now, I am trying
sudo ./bjam --toolset=darwin --link=static --threading=multi \
--architecture=combined --address-model=32_64 \
--macosx-version=10.4 --macosx-version-min=10.4 \
install
That compiles and install fine. However, the produced binaries seems broken.
az#ip245 47 (openlierox) %file /usr/local/lib/libboost_signals.a
/usr/local/lib/libboost_signals.a: current ar archive random library
az#ip245 49 (openlierox) %lipo -info /usr/local/lib/libboost_signals.a
input file /usr/local/lib/libboost_signals.a is not a fat file
Non-fat file: /usr/local/lib/libboost_signals.a is architecture: x86_64
Edit: It seems that the command was wrong and I must remove the "--" for most options. So the command I am trying now (-a just means to rebuild all):
sudo ./bjam -a toolset=darwin link=static threading=multi \
architecture=combined address-model=32_64 \
macosx-version=10.4 macosx-version-min=10.4 \
install
However, this gives many strange errors (what I already had earlier), all like this:
darwin.compile.c++.pch bin.v2/libs/math/build/darwin-4.2.1/release/address-model-32_64/architecture-combined/link-static/macosx-version-min-10.4/macosx-version-10.4/threading-multi/../src/tr1/pch.hpp.gch
In file included from ./boost/math/special_functions/acosh.hpp:18,
from ./boost/math/special_functions.hpp:15,
from libs/math/build/../src/tr1/pch.hpp:9:
./boost/config/no_tr1/cmath.hpp:21:19: error: cmath: No such file or directory
This could be another problem I have when building Universal binaries: g++ on MacOSX doesn't work with -arch ppc64
I found the problem. It seems that the MacOSX 10.4 SDK is missing a bunch of symlinks for GCC 4.2.
Use this as a test case:
g++ on MacOSX doesn't work with -arch ppc64
It will report multiple errors with GCC 4.2 (missing C++ includes, missing C includes, missing libs). In all cases, you can just fix that by setting a symlink. Search in your SDK for the file and just set the symlink in the same way it is in the MacOSX 10.5 SDK.
After that, it all just worked.
We use Boost compiled for 10.4 here at work. We don't use GCC 4.2 on it though, rather we use GCC 4.0 as Apple's GCC 4.2 is not supported for the MacOS 10.4 SDK. To accomplish this you need a bjam user config file, eg. user-config-darwin.jam. Here's the contents of ours. Modify to your heart's content:
# Boost.Build Configuration
# Compiler configuration
using darwin : 8.11 : /usr/bin/g++-4.0 :
<architecture>"combined"
<address-model>"32" # this can be changed to 32_64 for 32/64 universal builds
<macosx-version>"10.4"
<macosx-version-min>"10.4"
# <root>"/Developer"
<compileflags>""
<linkflags>"" ;
Then, you need to tell bjam to use the user config jam file when compiling:
bjam --user-config=user-config-darwin.jam ... (your other options go here) ...
Now you don't have to mess with symlinks in the system SDK directories.
To build 4-way universal boost static binaries on OSX 10.6 I do the following:
Download boost from the boost website.
Extract the archive and cd into the boost_1_xx_0 folder (where xx is the version of boost you are using).
Run:
./bootstrap.sh and then
./bjam macosx-version=10.6 macosx-version-min=10.4 architecture=combined threading=multi link=static address-model=32_64
This will compile everything except for Boost.MPI (which requires the --with-mpi option). The build products get put in ./stage