I'm trying use rebar to generate a 32-bit arch release on 64-bit arch system. It's unclear to me how I need to modify an application's rebar.config to be able to do this.
I have taken a look at the rebar source to see how they are detecting my environment: rebar_utils.erl gets the architecture as "x86_64-unknown-linux-gnu" and this is set in rebar_port_compiler as the "default_env". I'm wondering how I can get rebar to compile for another target architecture.
I have tried the following port_env options
{port_env, [{"CFLAGS", "$CFLAGS -fPIC -m32"},{"LDFLAGS", "-arch i386"}]}.
With those options (and a 32-bit Erlang installation in my path), when I run rebar get-deps compile my dependencies are still being built as 64-bit and thus ld skips over my 32-bit libraries (and ultimately fails because it cant find a 64-bit implementation)
/usr/bin/ld: skipping incompatible <PATH TO 32-bit erlang install>/lib/erlang/lib/erl_interface-3.7.14/lib/liberl_interface.a when searching for -lerl_interface
/usr/bin/ld: cannot find -lerl_interface
collect2: ld returned 1 exit status
ERROR: sh(cc c_src/epam.o $LDFLAGS -shared -L"<PATH TO 32-bit erlang install>/lib/erlang/lib/erl_interface-3.7.14/lib" -lerl_interface -lei -o priv/lib/epam.so)
What do I need to do to force my dependencies to compile as 32 bit? My attempt here isn't working.
The port_env settings in rebar.config can make use of the ERLANG_ARCH environment variable to determine whether the Erlang runtime was built for a 32- or 64-bit system. For example, the following port_env definition sets either -m32 or -m64 as appropriate for the C compiler for the x86_64, i686, and i386 chip architectures:
{port_env, [{"x86_64", "CFLAGS", "$CFLAGS -m$ERLANG_ARCH"},
{"i[36]86", "CFLAGS", "$CFLAGS -m$ERLANG_ARCH"}]}.
The first string in each tuple is a regular expression matched against the system architecture string of the Erlang runtime as returned by the erlang:system_info(system_architecture) function. In this example, the additional -m$ERLANG_ARCH option is added only when the regular expression matches, and all other architectures get the default CFLAGS setting.
Related
I have built libstdc++ with no modifications yet:
cd gccsrcdir/libstdc++-v3/build
../configure --prefix=$PWD/../install
make && make install
I am using Ubuntu 21.10 and I set the following environment variables:
export LIBRARY_PATH=gccsrcdir/libstdc++-v3/install/lib
export LD_LIBRARY_PATH=gccsrcdir/libstdc++-v3/install/lib
export CPLUS_INCLUDE_PATH=gccsrcdir/libstdc++-v3/install/include/c++/13.0.0
When I then use the system's GCC, I get no problems. When I use the system's Clang, it produces a symbol lookup error - even with no parameters:
clang++
clang++: symbol lookup error: /lib/x86_64-linux-gnu/libicuuc.so.67: undefined symbol: _ZSt15__once_callable, version GLIBCXX_3.4.11
In fact I only need to update LD_LIBRARY_PATH to arrive here. What am I doing wrong?
The symbol -- std::__once_callable is defined in your system libstdc++.so.6 (it has version GLIBCXX_3.4.11 in my build, which means it was added in GCC-4.4.0).
Your build of libstdc++.so.6 should define this symbol as well, but for some reason does not. That is a problem -- any binary which uses this symbol will fail at runtime when using your build of libstdc++.so.6 (which is happening because you've pointed LD_LIBRARY_PATH to it).
Note: in your case it's the clang++ binary that is failing to run -- any flags you add to it (such as -femulated-tls) are irrelevant -- they only affect the binary that would have been generated IF clang++ itself didn't fail.
I just repeated your configure && make steps, and the library built this way also doesn't define this symbol.
I then repeated the configure && make, but starting from top-level GCC directory, and libstdc++.so.6 built that way does define the symbol.
Conclusion: libstdc++ is configured differently during "normal" GCC build.
The definition comes from mutex.o, which is built from ./libstdc++-v3/src/c++11/mutex.cc, and which has this chunk of code:
#ifdef _GLIBCXX_HAS_GTHREADS
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
#ifdef _GLIBCXX_HAVE_TLS
__thread void* __once_callable;
__thread void (*__once_call)();
...
So it sounds like either _GLIBCXX_HAS_GTHREADS or _GLIBCXX_HAVE_TLS is not defined when doing configure && make in the libstdc++-v3 directly.
Digging further, I see that libstdc++-v3 determines _GLIBCXX_HAS_GTHREADS by trying to compile #include "gthr.h", and that file is available in libgcc/gthr.h, but not in "standard" installed GCC.
../libstdc++-v3/configure && grep _GLIBCXX_HAS_GTHREADS config.h
/* #undef _GLIBCXX_HAS_GTHREADS */
TL;DR: correctly configuring libstdc++.so is complicated, and you will be better off building complete GCC.
Once you have a complete build, you will have a libstdc++-v3 directory properly configured, and can just rebuilt in that directory:
grep _GLIBCXX_HAS_GTHREADS ./x86_64-pc-linux-gnu/libstdc++-v3/config.h
#define _GLIBCXX_HAS_GTHREADS 1
I have been using clang-3.5 to happily build bitcode versions of musl libc and
use the result to produce nice stand alone executables.
Recent attempts with clang-3.8 have not been so happy. It seems that
the bitcode clang-3.8 generates uses functions defined in
compiler-rt/lib/builtins
Typical examples of functions I find polluting the bitcode are mulxc3, mulsc3, and muldc3. I can solve this by linking against libgcc, or even the llvm alternative if I had any clear idea of what that was. Though I would rather prevent the problem from happening in the first place.
I have seen mention of flags like rtlib=compiler-rt etc, but have found precious little documentation on the subject.
So here are some simple questions.
Is it possible to prevent clang from using the compiler-rt/lib/builtins
in the emitted bitcode? Or if not
Does llvm produce a version of libgcc that I could use. Actually I would
probably build a bitcode version of it, but that is besides the point.
Love to hear some guidance on this.
Added 12/8/2016: So I will illustrate my issues with a particular workflow that
people can reproduce if they wish, or, more likely, just point out where I am being stupid.
So start by checking out:
musllv
and follow the instructions in the README.to compile (here I am using clang-3.8 on ubuntu 14.04)
WLLVM_CONFIGURE_ONLY=1 CC=wllvm ./configure --target=LLVM --build=LLVM
make
cd lib
extract-bc -b libc.a
you will also need the bitcode of a simple executable. I will use nweb.c here.
wllvm nweb.c -o nweb
extract-bc nweb
Now we can do things like:
clang -static -nostdlib nweb.bc libc.a.bc crt1.o libc.a -o nweb
This workflow goes smoothly for clang-3.5 but for clang-3.8 we get:
clang -static -nostdlib nweb.bc libc.a.bc crt1.o libc.a -o nweb
/tmp/libc-f734a3.o: In function `cpowl':
libc.a.bc:(.text+0xbb9a): undefined reference to `__mulxc3'
/tmp/libc-f734a3.o: In function `cpowf':
libc.a.bc:(.text+0x38f7d): undefined reference to `__mulsc3'
/tmp/libc-f734a3.o: In function `csqrt':
libc.a.bc:(.text+0x78fc3): undefined reference to `__muldc3'
/tmp/libc-f734a3.o: In function `cpow':
libc.a.bc:(.text+0xafafc): undefined reference to `__muldc3'
clang-3.8: error: linker command failed with exit code 1 (use -v to seeinvocation)
So as #paul-brannan points out we could try
clang -static -nostdlib --rtlib=compiler-rt nweb.bc libc.a.bc crt1.o libc.a -o nweb
But this is where I am probably being stupid, because I get:
clang-3.8: warning: argument unused during compilation: '--rtlib=compiler-rt'
irregardless of whether I use it as a linking or compiling flag.
OK so I finally managed to make headway on this. I built llvm-3.8.1 together with the compiler-rt project using wllvm and wllvm++.
One of the build products was libclang_rt.builtins-x86_64.a,
and from this archive I was able to extract the bitcode module
libclang_rt.builtins-x86_64.bc
using the command:
extract-bc -b libclang_rt.builtins-x86_64.a
This bitcode module has definitions for those pesky instrinsics like
__mulxc3, __mulsc3, and __muldc3.
Hallelujah!
I have been trying to enable the gold linker on FreeBSD to use the link time optimizations. I made gold from the binutils under /usr/ports. After building binutils using make -k install clean i got ld under /usr/bin and in the directory /usr/local/bin i got ld, ld.gold and ld.bfd.
Now while trying to use link time optimization for the simple example programs here http://llvm.org/docs/GoldPlugin.html (a.c and b.c under the heading 'Examples of Link Time Optimization') i entered the four commands as follows:
clang -flto a.c -c -o a.o
ar q a.a a.o
clang b.c -c -o b.o
clang -flto a.a b.o -o main
I got the following error:
usr/bin/ld: unrecogonized option '-plugin'
usr/bin/ld: use the --help option for usage information
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Is there the problem with the linker that ld.gold is not being called. Should I replace the ld with ld.gold? Does the linker looks in the right directiry for the .so plugins?
The LLVMgold.so and libLTO.so shared objects are in the directory /usr/local/llvm-devel/lib/.
I cannot find the directory where clang is installed. I am not sure where to make the bfd-plugins directory and add the symlinks to LLVMgold.so and libLTO.so.
I am using freebsd 10.1 release. How to enable the gold linker for link time optimizations?
also how can I enable it to be the default linker?
You may want to use ld.gold instead of ld. It is installed at /usr/local/bin/ld.gold. If you are using a Makefile, it would work by setting LD variable to ld.gold, either by modifying your Makefile or specifying it on command line. Example in case you are using lang/clang37:
gmake all CC=clang37 LD=ld.gold
EDIT:
It would be even more neat if you add -fuse-ld=gold to your LDFLAGS:
LDFLAGS=-fuse-ld=gold
I'm not sure ld.bfd allows plugins, but I could be wrong.
Your /usr/bin/ld should be a symlink to whatever linker you want. You can change which linker is used by using binutils-config. Check the man-page here: http://www.linuxhowtos.org/manpages/8/binutils-config.htm. I realise this is a Linux link, but it's directed at binutils itself rather than linux-specifically.
It should be something along the lines binutils-config --gold.
On my Gentoo box it is binutils --linker=gold
EDIT: As pointed out, binutils-config doesn't work on BSD it seems. You can still manually update the symlinks though, the downside is that there might be a few of them.
You can find out which ld is used by your compiler by using gcc -print-prog-name=ld or clang -print-prog-name=ld. The file printed should be a symlink you can re-create to point to ld.gold as oposed to ld.bfd.
I am trying to configure util-linux to cross compile using arm-none-linux-gnueabi from CodeSourcery. My only problem so far is that it can't find my ncurses library which I compiled.
How can I add a directory to the ld search path? I've tried adding to my LIBRARY_PATH and LD_LIBRARY_PATH variables, but neither does anything. I know that I can add the -L flag to gcc and it will add to the linker path, but is there any way to do this globally, so that I can do it once, and not have to worry about it again?
Here is the output of arm-none-linux-gnueabi-gcc -print-search-dirs | grep libraries | sed 's/:/\n/g':
libraries
=/tools/bin/../lib/gcc/arm-none-linux-gnueabi/4.6.1/
/tools/bin/../lib/gcc/
/tools/bin/../lib/gcc/arm-none-linux-gnueabi/4.6.1/../../../../arm-none-linux-gnueabi/lib/arm-none-linux-gnueabi/4.6.1/
/tools/bin/../lib/gcc/arm-none-linux-gnueabi/4.6.1/../../../../arm-none-linux-gnueabi/lib/
/tools/bin/../arm-none-linux-gnueabi/libc/lib/arm-none-linux-gnueabi/4.6.1/
/tools/bin/../arm-none-linux-gnueabi/libc/lib/
/tools/bin/../arm-none-linux-gnueabi/libc/usr/lib/arm-none-linux-gnueabi/4.6.1/
/tools/bin/../arm-none-linux-gnueabi/libc/usr/lib/
I would like to add /arm/usr/lib and /arm/usr/local/lib to my ld search path.
If you need output from any other commands, just ask!
EDIT: I just found out about the CFLAGS environment variable--do all configure scripts/makefiles honor it?
Thank you!
If the ncurses library you compiled are going to be linked to the ARM binary you are cross-compiling you can not use LD_LIBRARY_PATH! LD_LIBRARY_PATH is only used by the current run-time and is in no way used by the compiler or linker when building your application.
The use of CFLAGS depends on creator of Makefile. CFLAGS are not automatically used even if they are defined as an environment variable. Only tools like the autoconf tools can pick them up from the environment and use them automagically. In the Makefiles find something like:
$(CC) $(CFLAGS) ....
if this fragment exists then the Makefile uses the CFLAGS variable. LDFLAGS is the more appropriate environment variable to use for link-time options.
I'm trying to cross-compiling from Mac OS X to iOS. It was easy using clang to cross-compile a source to iOS target. We need only 3 parameters get it to work.
clang
-arch armv6
-isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk
-miphoneos-version-min=4.3
But the problem is I have to build a library (Bullet Physics) packaged with Cmake. And as far as I know, Cmake has no iOS support yet.
So, I made a toolchain file.
SET (CMAKE_SYSTEM_NAME "Generic")
SET (CMAKE_SYSTEM_VERSION "4.3")
SET (CMAKE_SYSTEM_PROCESSOR "arm")
SET (CMAKE_CROSSCOMPILING TRUE)
SET (SDKVER "4.3")
SET (DEVROOT "/Developer/Platforms/iPhoneOS.platform/Developer")
SET (SDKROOT "/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk")
SET (CMAKE_OSX_SYSROOT "${SDKROOT}")
SET (CMAKE_OSX_ARCHITECTURES "armv6" "armv7")
SET (CMAKE_C_COMPILER "${DEVROOT}/usr/bin/clang")
SET (CMAKE_CXX_COMPILER "${DEVROOT}/usr/bin/clang++")
SET (CMAKE_C_FLAGS "-arch armv6 -arch armv7 -isysroot ${SDKROOT} -std=c99 -x objective-c -DNDEBUG=1")
SET (CMAKE_CXX_FLAGS "-arch armv6 -arch armv7 -isysroot ${SDKROOT} -x objective-c++ -DNDEBUG=1")
SET (CMAKE_EXE_LINKER_FLAGS "-miphoneos-version-min=${SDKVER}")
SET (CMAKE_SHARED_LINKER_FLAGS "-miphoneos-version-min=${SDKVER}")
SET (CMAKE_MODULE_LINKER_FLAGS "-miphoneos-version-min=${SDKVER}")
SET (CMAKE_FIND_ROOT_PATH "${SDKROOT}" "${DEVROOT}")
SET (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
SET (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
And executed.
cmake -DCMAKE_TOOLCHAIN_FILE=../CMAKE_IPHONEOS_TOOLCHAIN.cmake ../bullet-2.78
cmake itself done well. make done well. All build complete without any error. However built binary was x64 non-fat binary instead of armv6/armv7 fat binary. Generated Makefile doesn't work for cross-compile. It doesn't seem to use compiler and flags (including -isysroot) when building. How can I make it use the parameters?
I solved this and built Bullet Physics for iOS.
Solution
Here's toolchain configuration that I used.
INCLUDE(CMakeForceCompiler)
SET (CMAKE_CROSSCOMPILING TRUE)
SET (CMAKE_SYSTEM_NAME "Darwin")
SET (CMAKE_SYSTEM_PROCESSOR "arm")
SET (SDKVER "4.3")
SET (DEVROOT "/Developer/Platforms/iPhoneOS.platform/Developer")
SET (SDKROOT "/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS${SDKVER}.sdk")
SET (CC "${DEVROOT}/usr/bin/clang")
SET (CXX "${DEVROOT}/usr/bin/clang++")
CMAKE_FORCE_C_COMPILER (${CC} CLang)
CMAKE_FORCE_CXX_COMPILER (${CXX} CLang)
SET (CMAKE_FIND_ROOT_PATH "${SDKROOT}" "${DEVROOT}")
SET (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
SET (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
And the build script. This is important!
PKG_NAME=bullet-2.78
BUILD_DIR=build
rm -rf ${PKG_NAME} ${BUILD_DIR}
tar -x -f ${PKG_NAME}-r2387.tar
mkdir build
cd build
DEVROOT=/Developer/Platforms/iPhoneOS.platform/Developer
SYSROOT=$DEVROOT/SDKs/iPhoneOS4.3.sdk
CC=$DEVROOT/usr/bin/clang
CXX=$DEVROOT/usr/bin/clang++
CFLAGS="-arch armv6 -arch armv7 -isysroot $SYSROOT -miphoneos-version-min=4.0"
CXXFLAGS=$CFLAGS
LDFLAGS=$CFLAGS
export CC=$CC
export CXX=$CXX
export CFLAGS=$CFLAGS
export CXXFLAGS=$CXXFLAGS
export LDFLAGS=$LDFLAGS
cmake ../$PKG_NAME -DCMAKE_TOOLCHAIN_FILE=../CMAKE_IPHONEOS_TOOLCHAIN.cmake
make
lipo -info src/LinearMath/libLinearMath.a
This is very minimal configuration. However you got the idea.
Description
First, the toolchain configuration is just a stage figuring out features available on target machine. But cross compilation to iOS require some special compiler flags, and this is exception situation described on Cmake wiki.
So I just forced specific compiler, and Cmake will skip compiler verification stage.
Second, all compiler flags needed for cross compilation offered via shell variable export in build script. This is very rough options, however important is we have to pass via shell variables. Not with toolchain configuration.
However some kind of toolchain configuration affects on generated Makefile. We have to specify correct CMAKE_SYSTEM_NAME (Darwin) and CMAKE_SYSTEM_PROCESSOR (arm).
Update
There is another trials. Anyway these don't work for me anymore.
http://code.google.com/p/ios-cmake/
http://www.ltengsoft.com/node/20
Here's one more. This looks promising.
http://immersedcode.org/2011/4/25/sdl-on-ios/
Update 2
Now Bullet includes a build script for iOS platforms. Anyway it's inconvenient because it does not handle special needs for simulator stuffs, and I wrote another build script which makes far library for debug/release mode.
https://github.com/Eonil/Bullet-PhysicsEngine-BuildScript