I'm using Ubuntu 18.04 VM and trying to find a way to valgrind check an arm-Linux executable. I've tried compiling with local gcc but ran into some problems. The executable is created by Makefile provided from project. I've tried linaro emulator, following guides online, but faced multiple issues which for each one I've searched on online for solutions but all failed. What are the ways I can valgrind?
As long as I can check program for memory leak, any way is fine.
What I get when I valgrind executable now:
valgrind: failed to start tool 'memcheck' for platform 'arm-linux': No such file or directory
The file it self is fyi:
nrf52832_xxaa.out: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped
I've searched through multiple posts for solutions but couldn't find any.
Cross compile valgrind, and execute on the target. There are no other ways. Can't even use qemu to execute valgrind.
It is mandatory to run the executable on the device.
Please consider the option to download the precompiled package for your arch example from https://packages.debian.org/search?keywords=valgrind, follow the mandatory dependencies, and install all on you embedded device. I use to base the version according to the installed version of libc.
Related
I'm trying to cross-build LÖVE (https://love2d.org) for an ARM Linux device (Rockchip RK3066) from Ubuntu 16.04.
As the documentation says, I installed all dependencies on Ubuntu and was able to build it (for Ubuntu, as a test). Now I'm going for the cross-build.
Before building, I have to run ./configure. So far I've been able to get the toolchain's gcc compiler to be accepted, but when it looks for the dependencies, I get this error:
checking for luajit5.1... no
checking for luajit51... no
checking for luajit... no
configure: error: Package requirements (luajit) were not met:
No package 'luajit' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables lua_CFLAGS
and lua_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
Could this be fixed by cross-building luajit for the device and add it to the toolchain binaries, or could I just try to make the ./configure script look for the luajit I installed in Ubuntu?
If it's the latter, would someone kindly point me on the right direction? I've opened like 20 pages already with a similar error message and none of them had a valid answer.
Thanks a lot in advance.
I wanted to start cross compiling for raspberry pi2 on Ubuntu 32bit (in virtual box), so I downloaded the toolchain on the github site (https://github.com/raspberrypi/tools) and tried to compile a simple hello world program with the command (I've included the path to the bin folder that contains arm-linux-gnueabihf-gcc-4.8.3 to the PATH variable.):
arm-linux-gnueabihf-gcc-4.8.3 HelloWorld.c
However, I always get the following error message:
path/to/the/linker/in/the/toolchain/ld:/path/to/the/libc.so.6file/in/the/toolchain/libc.so.6: file format not recognized; treating as linker script
and subsequently a syntax error.
When I look into libc.so.6, I see a single line containing:
libc-2.13.so
The libc-2.13.so file is present in the same folder as the libc.so.6 file. When I invoke
file libc-2.13.so
I get:
libc-2.13.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=dbd0cdca5a677bea1417be1272f4c5ef43bd3e22, for GNU/Linux 2.6.26, stripped
I don't know what could cause this error since obviously the linker from the toolchain and the libc.so.6 file from the toolchain are processed so the file format should be recognized, right?
Can someone point me in the right direction here? Thanks!
I will suggest you alternate way to do Cross compilation. I tried it and it works. You can use crosstool-NG. It gives you graphical way to setup your toolchain for cross compilation. There are lot of option for setting up toolchain. You can explore that.
Now you are doing for ARM-RPi but tomorrow if your Target CPU changed then it will be very easy to reconfigure the toolchain again.
You can find easy steps given in this article. I hope this works for you.
When I look into libc.so.6, I see a single line containing:
libc-2.13.so
I just ran into this.
The problem is way simpler than you think. When you un-gz'd and untar'd the toolchain, what happened is that libc.so.6 became a text file. It is supposed to be a "symbolic link" file pointing at the correct file "libc-2.13.so".
If you are using windows and 7-Zip, make sure to click "Run AS Administrator" when you start 7-zip. If you simply drag and drop, the error is not so obvious.
In my first effort, I had to include the path to gcc in the command. Then I just compiled programs on the RPi.
~/toolchain/raspbian-toolchain-gcc-4.7.2-linux32/bin/arm-linux-gnueabihf-gcc whets.c
I want to automate expect for passwd but I don't have permission to install.
But if I could copy and paste the expect source code and execute the .c files usingcc/gcc
and generate the executable expect.
or
Can I copy the expect executable from linux and just use it anywhere else like on solaris, aix etc?
This is the expect in /usr/bin/expect in my linux box:
[root#test]# file /usr/bin/expect
/usr/bin/expect: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
The prebuilt executables for Solaris and Linux at kbskit include Expect (along with lots of other Tcl extensions) in the *bi "Batteries Included" versions. Each is just one big file, no unpacking or installing is needed, apart from eg. chmod a+x SunOS_kbsvq8.5-bi to make the file executable. You use this executable to run your script, and at the start of the script you need to add package require Expect to set up the Expect commands.
If you have a C compiler, you can build expect (but you have to build Tcl first).
The executable from Linux can't be used almost anywhere else (on solaris, aix, etc.); there is a chance for it to work on FreeBSD.
If you are on Solaris 11 then installing expect is as easy as:
pkg install //solaris/shell/expect
The package will come from the official Oracle Solaris repository so nothing to worry about. There's no need to get sources, build, etc.
I understand that you may not have permission to do this but since this comes from official source (Oracle) I'm pretty sure your sysadmin will do it in a sec.
Ive been trying to setup mpich2 to compile some programs using MPI on windows 7. The problem that I encounter is that it wont create the binary files when I build a project.
I use the stadard mpi program to test (hello world) and I get this message after building it:
13:33:29 ** Rebuild of configuration Debug for project mpitest **
Info: Internal Builder is used for build mpiCC "-IC:\MPICH2\include"
-O0 -g3 -Wall -c -fmessage-length=0 -o "src\mpitest.o" "..\src\mpitest.c"
The Open MPI wrapper compiler was unable to find the specified
compiler cl.exe in your PATH.
Note that this compiler was either specified at configure time or in one of several
possible environment variables.
13:33:29 Build Finished (took 78ms)
I tried to search for cl.exe but it doesn't exist. I have to say that I also installed openMPI but I didn't use it cause the cluster that I am gonna target run the program is using MPICH2. I have already installed 32bit minGW, 32bit MPICH2 and 32bit openMPI.
Is it normal to not create binaries since i run the .c file in the cluster? If its normal how am i going to check if the program is ok even for 1 process?
Thanks in advance! Cheers!
I found the answer by luck... In the project preferences, select C/C++ build-> Tool Chain editor-> choose cygwin and its done. For some reason i had mingw in that option and wouldnt create binaries, i suppose it needs some other tools that can be found only in the cygwin and not mingw... Still trying to set it and run on the cluster... so many options :/
I am compiling a program through clang+llvm (version 3.1) and trying to run it on a computer which also has the same clang+llvm version. I'm compiling on Ubuntu 10, but the other computer where I'm trying to run has CentOS 5. There (in CentOS), I also encounter problems compiling through LLVM (a compiler pass is implemented in LLVM). That is why I thought about compiling on Ubuntu, take the exe from there and just run it on the CentOS machine.
However, when I try to do that, I get the following error.
./main: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./main)
./main: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./main)
How can I solve this. Please note that I do not have root accesses on that machine.
One solution would be to copy the library from your working Ubuntu machine to your CentOS machine. Put in your Home/Workdir/whereever(TM) and set your LD_PRELOAD variable to that library. But that can be quite tedious as it is possible that this is not the only library that is missing (and maybe libraries depend on other libraries, that you also need...).
This also only works, if both machines have the same architecture (e.g. it wont work if your ubuntu machine is 32 bit and your CentOS 64).
Centos 5 uses an older version of libstdc++ than Ubuntu 11.04 or 11.10, so can't use binaries from there.
Either compile on Centos 5, or find a older compile environment that does work. If you were using gcc, you could also investigate the LSB compiler environment.
Cross compilation is always a difficult issue. In your case you have different c++ library versions on the two machines. In case you do not need to do this often, I suggest you try and solve your compilation issue on CentOS. It's probably the easier way round.