Right now I'm using the following:
export CFLAGS="-O2-isysroot/Developer/SDKs/MacOSX10.5.sdk -arch i386 -I/sw/include/"
export LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk,-L/sw/lib/"
sudo ./configure --prefix=/sw --with-quantum-depth=16 --disable-dependency-tracking --with-x=no --without-perl --enable-static --disable-shared --with-jpeg --with-tiff --disable-assert make
The code above still generates an 'identify' tool with asserts. I'm testing this by identifying a corrupted png image. Identify just crashes/exits with an assert. I'm running this on a Mac.
Any suggestions to build release mode without any asserts?
(I'm anticipating a really simple solution :) )
When running configure do this:
./configure DEFS=-DNDEBUG
The idea is to have NDEBUG defined.
Related
I'm trying to cross-compile Google Breakpad. I'm executing the following commands:
$ ./configure --prefix=/opt/breakpad CFLAGS="-Os" CC=PATH_ARM_COMPILER/arm-linux-gcc CXX=PATH_ARM_COMPILER/arm-linux-g++ --host=arm
$ make
$ make install
It generates and installs some files in the prefix path. In the include path it has:
|-common
|-google_breakpad
|-processor
but it should has:
|-client
|-common
|-google_breakpad
|-processor
|-third_party
It seems to be a problem related to Breakpad client. What should be the right way to cross-compile Breakpad?
My host is a Ubuntu 18.04 x86-64, target ARM-32.
I have reproduced your problem on my side. In fact, the issue is related to --host compilation flag.
Breakpad documentation shows that:
when building on Linux it will also build the client libraries.
So, In order to get the client binaries and headers, you should use the correct compiler prefix.
For example if you are using the GNU cross compiler arm-linux-gnueabihf-gcc, the --host flag value should be arm-linux-gnueabihf.
In your case (arm-linux-gcc) try to change your configure command as following:
./configure --prefix=/opt/breakpad CFLAGS="-Os" CC=PATH_ARM_COMPILER/arm-linux-gcc CXX=PATH_ARM_COMPILER/arm-linux-g++ --host=arm-linux
I have a simple helloworld.cpp to instrument with Score-P or Vampirtrace.
Installation of the performance/ tracing tools works fine. After compiling and running:
# score-p
scorep-g++ helloworld.cpp -o hello
export SCOREP_ENABLE_TRACING=true
export SCOREP_ENABLE_PROFILING=true
# vampirtrace
vtcxx -DVTRACE helloworld.cpp -o hello
# run
./hello
The created OTF files (OTF for vampirtrace/ OTF2 for Score-P) are more or less empty (no timeline data). I'm using Vampir to visualize the data.
More details:
I'm testing on Mac OS X (g++-8) and Xubuntu (g++-7; VirtualBox).
For Mac OS X I have installed brew install gcc.
For the instrumented Score-P version I also got a warning
[Score-P] src/measurement/profiling/scorep_profile_callpath.c:206: Warning: Master thread contains no regions.
but I can't find related issues/ help.
I also installed TAU and PDT for Vampirtrace, but nothing changed. By the way manual instrumentation works for Vampirtrace:
#include "vt_user.h"
...
VT_TRACER("name");
For Vampirtrace I also tested OpenMP instrumentation and this was working, but only that (no application tracing around).
For both environments I did not install Open MPI.
It would be great, if somebody has similar issues and could help.
PS: Later, I want to instrument an application with Poco::Threads. I only read about partial support for POSIX Threads.
Update
The problem is g++. I tried the same instrumentation with Intel icc and it worked.
The missing instrumentation with g++ is also possible with icc, if you add the parameter --nocompiler like
score-p --nocompiler icc helloworld.cpp -o hello
Update
I had to install missing packages. There are logging outputs for ./configure with hints. One of the following package solved it:
apt-get install llvm libwrap0-dev libclang-dev gcc-7-plugin-dev
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
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.