I need to debug a multi-threaded program which keeps throwing horrible segmentation faults, and I chose Valgrind to do so. The problem, though, is that the code is cross-compiled and run in an ARMv5 machine. I tried to build Valgrind for that architecture, but configure failed because that version is not supported:
$ CC=arm-linux-gnueabi-gcc ./configure --prefix=/opt/valgrind \
--host=armv5-none-linux-gnueabi --target=arm-none-linux-gnueabi \
--build=i386-ubuntu-linux
(...)
checking for a supported CPU... no (armv5)
configure: error: Unsupported host architecture. Sorry
Is there a way to solve this issue? Could it be somehow possible to compile for ARMv7 (which I read is fully supported), and use it in my platform? I found this question, but it was asked two years ago and the answer points to a patch for older versions of Valgrind.
If you get to compile valgrind for an ARMv5 instruction set CPU you cannot run it since valgrind only runs on ARMv7 CPUs.
Valgrind cross compilation for ARMv5tel
ARM support seems to be added since "Release 3.6.0 (21 October 2010)":
http://valgrind.org/docs/manual/dist.news.html
But it has to run on an ARMv7 CPU even if it supports older instruction sets.
I compiled valgrind for an ARMv5 and it does not run, it throws "Illegal instruction".
https://community.nxp.com/message/863066?commentID=863066#comment-863066
In configure file change "armv7*" to "arm", then your compilation will success.
Related
I am want to compile linux 5.10.162 with CONFIG_DEBUG_INFO_BTF=y, the end goal being to enable bpf CO-RE. However, the build is failing with:
+ ./tools/bpf/resolve_btfids/resolve_btfids vmlinux
FAILED unresolved symbol udp_sock
I first thought it was something similar to this issue, but after moving to a newer gcc, the issue persists.
Relevant packages:
gcc 11.1.0 (also tested with 10.2)
dwarves 1.24 (also tested with 1.22)
Bear in mind don't have much experience compiling linux. Let me know if the config will be of use.
I tried almost a hundred things to make this works but nothing seems to be working.
I recently acquire a Mac book pro M1 MAX (so arm64 architecture), system provided by default with clang g++.
I wanted to install boost library. Using homebrew the 1.80 version was installed but I need to work on a project with the 1.65.1 version (I tried compiling my project with 1.80 version and tons of undefined symbols and errors were raised from boost library even if I have all of them, so I'm guessing I need to install the exact same version required)
so I decided to build and compile boost by myself following the boost guide
https://www.boost.org/doc/libs/1_65_1/more/getting_started/unix-variants.html
Following section 5.1 I tried to use the bootstrap script and this one fails using Darwin toolset. (apparently some Clang warning caused error). I resolve then by changing the boost source code like this :
https://github.com/boostorg/build/commit/48e9017139dd94446633480661e5447c7e0d8b1b
But there's still lot of issues during the compilation
I don't know what to do to be able to compile with clang, I don't even know if this will be compiled for arm64 architecture.
anyway I install gcc compiler and tried with gcc toolset.
./bootstrap --with-toolset=gcc
The bootstraps works but then running the b2 script cause a segmentation fault instantly and on every commands I tried (even the --help options raised an exception...).
Why is building boost so complicated on arm chipset ?
What can I do to build boost (either clang or gcc, arm or cross compiled universal library) ?
I'm desperate at this point.
Thanks for the help.
I tried everything
with clang (darwin)
with gcc
with options to add arm64 as architecture
changing the source code of boost to fix
I am trying to use pocl to cross-compile OpenCL programs for RISCV64. Slide 18 at this link: https://riscv.org/wp-content/uploads/2015/01/riscv-software-toolchain-workshop-jan2015.pdf seems to suggest that it is possible to generate scalar code for the RISCV backend. I am using pocl-0.8 (based on llvm 3.3 since that is the stable version for the riscv-llvm backend).
I ran the configure command as follows:
./configure CC=/path/to/riscv/bin/riscv64-unknown-elf-gcc CXX=/path/to/riscv/bin/riscv64-unknown-elf-g++ --host=riscv64-unknown-elf
I got the following error:
configure: error: unable to find the libtool dl library (usually libltdl-dev)
I don't get any error if I configure pocl for my native system (x86_64). So, I am guessing I need the RISCV variant of the library mentioned in the error message above but I am not sure how to do that. I would appreciate any help with this. Thanks!
Do you want to run pocl on the RISC-V system generating RISC-V code or to run it on host x64 system to generate RISC-V?
Your configure command
./configure CC=riscv64-unknown-elf-gcc CXX=riscv64-unknown-elf-g++ --host=riscv64-unknown-elf
is for compiling native pocl on RISC-V which is hard (you need full cross-environment and RISC-V target cpu/emulator/board with linux, libc, and many packets). And even for this it is incorrect, as your host (machine where you start compilation of the pocl) is not riscv, but x64 (use --target to set target architecture in configure).
But if you want to run pocl on x64, don't set CC and CXX, host and target in ./configure run to get native x64 pocl. llvm will have all backend and will let you to generate RISC-V codes, when starting pocl on x64.
I have just upgraded to OS X 10.8 "Mountain Lion" and I start regretting having done that.
I am no longer able to build my (simple) parallel code that uses OpenMP.
By looking here and there I understood that Apple is no more using 'gcc' but 'llvm' - quite likely due to licence-related issues. Unfortunately 'llvm' does not (yet?) support OpenMP.
I cannot believe many programs based on OpenMP will not run any more on OS X, so my question is: how can I enable OpenMP in Mountain Lion?
After reading the excellent answer of Hristo Iliev, I think I missing more than I initially thought.
I am not using XCode. The building is based on CMake and make/gcc. Yesterday I installed gcc 4.2 via macports, but - as of today - my code is still in source form because - for some strange reasons - I am not able to switch the compilation to gcc (same errors related to OpenMP).
The problem now is that CMake keeps using the llvm compiler.
In the root CMakeLists.txt I added the following two lines:
set(CMAKE_C_COMPILER "/opt/local/bin/gcc-apple-4.2")
set(CMAKE_CXX_COMPILER "/opt/local/bin/gcc-apple-4.2")
and I also added two environments variables:
export CXX=/opt/local/bin/gcc-apple-4.2
export CC=/opt/local/bin/gcc-apple-4.2
When CMake tries to find OpenMP ( FIND_PACKAGE(OpenMP) ) I get the following output:
-- The compiler is /opt/local/bin/gcc-apple-4.2
-- Try OpenMP C flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
[...]
CMake Error at /opt/local/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97 (message):
Could NOT find OpenMP (missing: OpenMP_C_FLAGS OpenMP_CXX_FLAGS)
Call Stack (most recent call first):
/opt/local/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:291 (_FPHSA_FAILURE_MESSAGE)
/opt/local/share/cmake-2.8/Modules/FindOpenMP.cmake:159 (find_package_handle_standard_args)
demo/CMakeLists.txt:8 (FIND_PACKAGE)
I tried to run /opt/local/bin/gcc-apple-4.2 manually and it fails due to a missing libgomp.
Regards
LLVM is a compiler framework that Apple uses extensively in OS X (most notably in the OpenGL implementation), not a compiler itself. There are two LLVM frontends available in Xcode - the old GCC-based one llvm-gcc (which supports OpenMP 2.5) and the new clang (which does not support OpenMP). clang has extensive static code analysis capabilities and also much nicer error reporting, especially with C++ code. Mostly that's the reason Apple is investing in it and moving away from GCC (the FreeBSD project, on the other side, is seeking to replace GCC with clang for purely license-related reasons). There is an ongoing project clomp (not to be mistaken with Intel's Cluster OpenMP) that seeks to create an OpenMP-aware version of clang, but it is far from mature.
If you do not need new OpenMP constructs like explicit tasks and can live with some bugs, you can still use the old GCC frontend. Just switch the compiler suite in the project settings to LLVM GCC 4.2:
This one is based on the really ancient GCC 4.2.1 and no longer seems to be developed. Should you need a newer version of GCC, simply build one. Unfortunately I cannot provide you with information on how to integrate it into Xcode. It works for me on the command line with GCC 4.7.1 and OS X 10.8.2 (and I don't use Xcode much).
Just adding few words to excellent Hristo's answer: you can install gcc via MacPorts. This is much simpler than compiling everything by hands (and compiling gcc from scratch might be really non-trivial task due to dependencies, etc).
So, install MacPorts, do "sudo port install gcc47", wait few hours and you'll end with gcc-mp-4.7 which is able to compile your OpenMP code.
I am working on a project and i want to compile valgrind using uClibc.
Can anyone suggest me something about how to proceed?
I am using fedora and i386 platform. the target platform is also i386 at the moment later on would work on MIPS.
thanks
Valgrind does not support the MIPS instruction set, so unless you put some significant effort to port Valgrind on MIPS, it is not possible to use Valgrind on this architecture.
we can use toolchain provided by buildroot. Just install it and cross compile the valgind .