I am trying to compile kernel for Cyanogenmod 13. I am getting error
ERROR: modpost: Found 2 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
To build the kernel despite the mismatches, build with:
'make CONFIG_NO_ERROR_ON_MISMATCH=y'
(NOTE: This is not recommended)
I read it here. That i need to compile my kernel using 4.7.
How can i choose the version of toolchain during cyanogenmod build ??
I believe you need to setup gcc version 4.7 and use CC variable to set it as a compiler. E.g. make target CC=/bin/gcc4.7
More information here and here.
Thanks to #nopasara and his valuable comment.
So i did little research further and discovered that the kernel is compatiable with arm-eabi tool chain not arm-linux-androideabi toolchain. So here is the command i used
export PATH=$PATH:~/android/system/prebuilts/gcc/linux-x86/arm/arm-linux-eabi-4.7/bin/ && export ARCH=arm && export SUBARCH=arm && export CROSS_COMPILE=arm-linux-eabi- && make msm8226_defconfig O=~/android/system/out/target/product/E6790/obj/KERNEL_OBJ
and
make O=~/android/system/out/target/product/E6790/obj/KERNEL_OBJ zImage -j4
To do with this Cyanogenmod add following line to your BoardConfig.mk
TARGET_KERNEL_CROSS_COMPILE_PREFIX := arm-eabi-
and either use
export TARGET_LEGACY_GCC_VERSION=4.7
Or edit ~/android/system/build/core/combo/TARGET_linux-arm.mk and set version in
$(combo_2nd_arch_prefix)TARGET_LEGACY_GCC_VERSION := 4.7
Related
The python configure.py contains a line
gcc_linker_output = subprocess.check_output(['gcc', '-###', '/dev/null', '-o', 't'], stderr=subprocess.STDOUT).decode('utf-8')
The comments before this line indicate scylladb uses a custom dynamic linker and references details about the ABI layout.
Is there code missing from the configure.py script which would enable building on a strict llvm environment, or is that not possible at this time?
I am building Scylladb on FreeBSD 13 which uses clang++ 13.0.0.
I am on branch master, commit 0efdc45d5981868b1b6, Setp 8, 2022.
I patched SCYLLA-VERSION-GEN to get past the date --utf and USAGE issues, and patched config.py with an entry to read ID from freebsd for the boost error message.
I run configure.py with
./configure.py --mode=release --compiler=clang++ --cflags=-I/usr/local/include
In fact ScyllaDB builds with clang. However its dependency Seastar is very dependent on Linux. If you want it to run on FreeBSD you'll have to port Seastar first (see reactor_backend.{cc,hh})
I am trying to cross compile a package for MIPS architecture using toolchain provided by OpenWRT. I come across following error during make:
/usr/bin/ld: skipping incompatible /home/user/package/zlib/zlib-1.2.8/libz.so when searching for -lz
In this case zlib is already cross compiled for MIPS but make is using '/usr/bin/ld' instead of 'mipsel-openwrt-linux-ld'. I have tried ./configure with --with-ld option but it says that '--with-ld' is unknown option.
Did you check following page, https://wiki.openwrt.org/doc/devel/crosscompile?
Pass the host and build to the build system of the package to trigger cross-compile
For GNU configure, use --build=architecture-unkown-linux-gnu --host=architecture-openwrt-linux-uclibc (for example: ./configure --build=x86_64-unkown-linux-gnu –host=mips-openwrt-linux-uclibc)
Run ./config.guess to get the --build= option.
Check the output and ensure that 'checking whether we are cross compiling… yes' is yes.
For GNU make, override the CC and LD environment variables (usually not needed if GNU configure was used)
make CC=architecture-openwrt-linux-uclibc-gcc LD=architecture-openwrt-linux-uclibc-ld
I know that this two years old. I had the same issue when building foreign packages for OpenWrt.
As for the most recent OpenWrt, you have set at least two ENV variables:
add your Path_to_OpenWrt/staging_dir/toolchain-*/bin path to your PATH ENV var
set your Path_to_OpenWrt/staging_dir to your STAGING_DIR ENV var
You should now be able to compile an autoconf based project with AC_CANONICAL_HOST (look it up in the configure.ac) with ./configure --host=architecture-openwrt-linux.
You probably will need to set more ENV vars e.g. PKG_CONFIG_PATH, PKG_CONFIG_LIBDIR to make pkg-config work appropriately.
I have written a bash script which does all the work for you:
sdkenv.sh.
You can activate the script with source sdkenv.sh before configuring.
OK, so first of all I know that this can be compiled on iOS (armv7) because I read the documentation. However, I can't find the right toolchain.
So, now, what toolchains I've already tried:
i686-apple-darwin10-cpp-4.2.1
i686-apple-darwin10-g++-4.2.1
i686-apple-darwin10-gcc-4.2.1
The above cross-compiles to x86 (I'm on i386). Works fine. But I don't need it
arm-apple-darwin10-cpp-4.2.1
arm-apple-darwin10-g++-4.2.1
arm-apple-darwin10-gcc-4.2.1
The above compiles fine, but doesn't cross compile to arm as I would have expected, instead, it simply compiles to my current arch.
I'm a real beginner in this matter, in fact this is my first attempt to cross-compile something.
UPDATE:
Here are the commands that I've tried(this is for armv6; armv7 is similar):
configure:
../llvm/configure --host=arm-apple-darwin6 --target=arm-apple-darwin6
--build=i386-apple-darwin --enable-optimized --disable-debug
--disable-expensive-checks --disable-doxygen --disable-threads
env vars:
export DEVROOT=/Developer/Platforms/iPhoneOS.platform/Developer
export SDKROOT=$DEVROOT/SDKs/iPhoneOS$IOS_BASE_SDK.sdk
export CFLAGS="-arch armv6 -pipe -no-cpp-precomp -isysroot $SDKROOT -miphoneos-version-min=$IOS_DEPLOY_TGT -I$SDKROOT/usr/include/"
export CPP="$DEVROOT/usr/bin/arm-apple-darwin10-cpp-4.2.1"
export CXX="$DEVROOT/usr/bin/arm-apple-darwin10-g++-4.2.1"
export CXXCPP="$DEVROOT/usr/bin/arm-apple-darwin10-cpp-4.2.1"
export CC="$DEVROOT/usr/bin/arm-apple-darwin10-gcc-4.2.1"
export LD=$DEVROOT/usr/bin/ld
export AR=$DEVROOT/usr/bin/ar
export AS=$DEVROOT/usr/bin/as
export NM=$DEVROOT/usr/bin/nm
export RANLIB=$DEVROOT/usr/bin/ranlib
export LDFLAGS="-L$SDKROOT/usr/lib/"
export CPPFLAGS=$CFLAGS
export CXXFLAGS=$CFLAGS
UPDATE : The purpose of this cross compile is to make an armv7(armv6) library not a command line tool.
YET ANOTHER UPDATE: I used the following:
CC="$DEVROOT/usr/bin/clang"
CXX="$DEVROOT/usr/bin/clang++"
./llvm/configure --host=i386-apple-darwin --target=armv7-apple-darwin --build=armv7-apple-darwin --enable-optimized --disable-debug --disable-expensive-checks --disable-doxygen --disable-threads --enable-targets=arm
And I managed to get checking whether we are cross compiling... yes out of the configure tool. However, make still outputs a x86_64 binary:(
In principle your configure invocation looks good. I'm trying to shoot a few typical mistakes:
Did you make clean after every change of architecture?
Why are you so sure that the LD, RANLIB etc. of your host system are fine for cross-compilation? It will overwrite the auto-configured value of LD. (The line reading "export LD=ld" would be at fault here.)
Could you check a typical compiler and a typical linker invocation in the output of make for their correct use of the cross-compilation tools?
I need some simple example to start using clang.
I downloaded llvm and clang and built:
mkdir llvm-build
cd llvm-build
../llvm/configure
make
I tried to build PrintFunctionNames from clang examples but got an error message:
../../../../Makefile.common:61: ../../../../Makefile.config: No such file or directory
../../../../Makefile.common:69: /Makefile.rules: No such file or directory
make: * No rule to make target `/Makefile.rules'. Stop.
Readme file says that only make is needed.
So how to build this plugin?
Go into llvm-build/tools/clang, and run "make BUILD_EXAMPLES=1".
Most assuredly you will have your LLVM trunk checkout and under the tools path you have checked out Clang trunk as well [explained under building Clang via http://clang.llvm.org/get_started.html.
Makefile Build Guide: http://llvm.org/docs/MakefileGuide.html
On OS X the build set up is a bit different, but on Debian Linux I'm building it daily as follows:
../trunk/configure --enable-target=x86_64,arm,cpp,cbe --with-built-clang --enable-pic --enable-polly --enable-shared --with-cxx-include-arch=x86_64 --enable-optimized --with-optimize-option=-Os --enable-assertions --disable-bootstrap --disable-multilib --enable-jit --enable-threads --no-create --no-recursion
then applying the make -j (n+1 number of cores) on the command for my Pentium D 945 system:
make [building against autotools make -j (n+1) doesn't always building llvm cleanly as it does against cmake. So if you want to run all cores, expect the possibility of running make -j(n+1) more than once to result in a clean build.
Standard form without accessing multiple cores:
make BUILD_EXAMPLES='1' //Read the note below
always results in a clean build, and if it doesn't report a bug to LLVM.
Note: If you're at the top level you can svn update the llvm trunk, project-test trunk and clang trunk as follows:
make trunk
Then go and run make again now that BUILD_EXAMPLES=1 is configured ahead of time.
make BUILD_EXAMPLES='1'
NOTE: Autotools will allow one to configure the BUILD_EXAMPLES='1' but will ignore the flag when you go to run make if you don't explicitly include BUILD_EXAMPLES='1' after make on the command line.
At the top of the LLVM tree you build against running make BUILD_EXAMPLES='1' will build the LLVM specific examples, then going inside your build/tools/clang path you then must run make BUILD_EXAMPLES='1' again to build the Clang examples.
Hence:
LLVM Top:
make BUILD_EXAMPLES='1' // for LLVM examples
cd tools/clang
make BUILD_EXAMPLES='1' // for Clang specific examples
Verify the examples installing under /usr/local/bin for LLVM and /usr/local/lib/ for Clang.
If you use CMAKE the default location for the binary examples is under /usr/local/examples
I followed the instructions at http://clang.llvm.org/get_started.html with two exceptions:
My build dir is inside the source dir (i.e. cd llvm ; mkdir build), but I don't think it's relevant.
I issued cmake as so :
cd build
cmake -DLLVM_BUILD_EXAMPLES=1 -DCLANG_BUILD_EXAMPLES=1 ..
After that (and compiling of course (make -j8)) I could find the examples in the build dir :
find -iname '*printfunctionname*'
./lib/PrintFunctionNames.so
...
I tried to do something similar yesterday: get a list of methods in a class using clang and succeeded. Maybe my post helps here also. My best help was this AST Matchers tutorial.
When using gcc version 4.3.2, I see how to generate specs using:
$ /usr/local/gcc-4.3.2/bin/gcc -v
Using built-in specs
Now changing to the same directory as libgcc:
cd /usr/local/gcc-4.3.2/lib/gcc/x86_64-unknown-linux-gnu/4.3.2
/usr/local/gcc-4.3.2/bin/gcc -dumpspecs > specs
I have a populated specs file that I can modify. However, once that is done I still see that:
$ /usr/local/gcc-4.3.2/bin/gcc -v
Using built-in specs
How do I tell gcc to use that specs file by default rather than forcing me to pass a -specs parameter every compile? I would like it to match another system I have where I get the following:
$ /usr/local/gcc-4.3.2/bin/gcc -v
Reading specs from /usr/local/gcc-4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/specs</code>
As you can see, the major difference between the two systems is that the existing setup is 32-bit and I am now trying to match that on a 64-bit system. The version of Linux is otherwise the same and I am compiling the same version of gcc. (With both systems gcc 4.3.2 is the second gcc installation, with 4.1.2 being used to compile 4.3.2)
As hinted at by the strace suggestion by Johannes Schaub - litb, it was a problem with where the compiler was looking for the file. As it turns out, the non-working installation had an environment variable set in the .bashrc that was causing the confusion.
The correct location for the specs file is indeed the same directory that libgcc is in. Just be sure you're looking there.
I used this command line:
/usr/bin/set-gcc-default-3.sh i686-pc-mingw32
but you'll probably want:
/usr/bin/set-gcc-default-4.sh i686-pc-linux-gnu
(Note the -4 instead of -3)
This is built using the "alternatives" stuff, please see
/usr/sbin/alternatives.exe --help
And also see pages such as http://linux.about.com/library/cmd/blcmdl8_alternatives.htm
You rebuild gcc with your specs file as part of the build!
A simpler solution is to create an alias:
alias gcc_Gary gcc -specs /<folder With Specs File>/newSpecsFile