I have a noob question. I have a minimal system(a headless linux) on my Raspberry Pi 3. I wanted to compile a C program. However I do not see the gcc binary. All I see is the libgcc_s.so library. How can I proceed with compilation. What do I need to "get" the gcc into the system.
Thanks.
Related
I'm trying to follow this blog but on Windows and with the latest Rust. It seems to me that the correct way of doing things like this is changing very frequently with Rust, so I'm hoping for an up-to-date Windows adaptation.
What I've tried so far:
I installed gcc-arm-embedded.
I had unverified partial success manually cross-compiling libcore, but then I switched to use the recommended xargo, the functionality of which (I read) is on its way to being included in Cargo eventually. While I don't understand any of it very well, I'm hoping to get to the part where I can write/run the code and then maybe I can back into understanding the compilation better.
With japaric's awesome help, I was able to get the "aarch64" targeted build working to generate the .o file (as of this particular commit).
And this part seems to verify:
$ file target/aarch64-raspi3-none-elf/release/deps/rust_rasp-ed0c2377e0a7df81.o
target/aarch64-raspi3-none-elf/release/deps/rust_rasp-ed0c2377e0a7df81.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), not stripped
When I try to use the GNU Arm Embedded Toolchain linker, I get:
$ arm-none-eabi-gcc -O0 -mfpu=vfp -mfloat-abi=hard -march=armv6zk -mtune=arm1176jzf-s -nostartfiles target/aarch64-raspi3-none-elf/release/deps/rust_rasp-ed0c2377e0a7df81.o -o kernel.elf target/aarch64-raspi3-none-elf/release/deps/rust_rasp-ed0c2377e0a7df81.o: file not recognized: File format not recognized
collect2.exe: error: ld returned 1 exit status
And #rust IRC chatroom helpfuls told me that rpi3 is aarch64, not arm, so I need to find an aarch64 linker ...
I think it's working! Things I learned:
xargo is good
rpi3 is different enough from rpi2 to cause my problems in tool selection
xargo doesn't care what toolchain rustup defaults to because I'm not asking it to link for me and it does its own toolchain selection
I needed to target aarch64, not arm. For this I used the linaro aarch64 mingw32 download, unpacked, added its bin folder to my PATH. Then the aarch64 tools were easy to adapt from the blog.
For people who want to do this themselves, see https://github.com/JasonKleban/rust-rasp . Not so complicated!
I aim to blink the onboard activity led as confirmation that we do really have control, but looks like that will be kinda complicated on the rpi3 (see my readme, if still applicable)
I'm trying to integrate Octave interpreter into my rigid body simulator compiled with GCC 4.8.1.
Following steps posted in the official documentation (https://www.gnu.org/software/octave/doc/interpreter/Standalone-Programs.html) allow me to compile, link, and successfully execute the first example. Note, that I can link the executable with both mkoctfile.exe, or g++ when minGW 4.8.1 is added to PATH.
However, the second example showing how to embed the interpreter into my program compiles, links, and then segfaults on execution when GCC 4.8.1 binaries are in PATH. It works, when I use the supplied compiler (in my case it's gcc 4.6.2 shipped with octave 3.6.1 on windows).
Do I need to build octave from source using GCC 4.8.1 in order to successfully link program compiled using that version, or is there any other way to do so?
Using GCC 4.6.2 is not an option for me, as my program uses c++11 features not present in that version.
I just learned that there is a newer Octave version available at http://mxeoctave.osuv.de/ which was compiled with GCC 4.9.2. This version of GCC works for me perfectly and the second example provided in the documentation started to work when compiled with g++ provided with the distribution.
I build a cross compile toolchain on OSX with:
binutils-2.23.52
gcc-4.6.4
gcc-core-4.6.4
gcc-g++-4.6.4
gdb-7.6.1
gmp-4.3.2
mpc-1.0.1
mpfr-2.4.2
newlib-2.0.0
for the target EFM32 wich is a ARM Cortex-m3, so the gcc target is arm-none-eabi.
All compiled fine.
But making programs with this toolchain like blink.c don't actually run on the EFM32 board.
I checked the blink.bin I did with a binary created with a IAR commercial toolchain delivered in the demos from energymicro, also gcc based and the they look very different internally (as expected :).
So has my toolchain wrong libs/versions or is it simply a matter of gcc/ld/ar switches wrong and what would be the steps to systematicly analyse this?
The problem
We are trying to compile the spi_slave code on a raspberry pi. We used the native gcc compiler and the compile runs without any errors.
The problem is when I try to run the output:
/home/pi/spi_slave# ./build/output.elf
Segmentation fault
/home/pi/spi_slave# ./build/kernel.img
bash: ./build/kernel.img: cannot execute binary file
Tried to download the arm-none-eabi compiler from cambridge but it wont run:
/home/pi/spi_slave# ../arm-2008q3/bin/arm-none-eabi-gcc
bash: ../arm-2008q3/bin/arm-none-eabi-gcc: cannot execute binary file
Sourcecode
The code we are trying to compile is: http://tylernichols.me/wp-content/uploads/2012/11/raspberry_pi_bare_metal_spi_slave.zip
The only change we did was in the makefile, added a # in front of the ARMGNU var
#ARMGNU = arm-none-eabi
Environement
# uname -a
Linux raspberrypi 3.6.11+ #371 PREEMPT Thu Feb 7 16:31:35 GMT 2013 armv6l GNU/Linux
What am I doing wrong?
We have tried to find answers on google and stackoverflow for hours now without success. :/
arm-none-eabi is a non-linux compiler. It is for bare-metal applications. The difference is in the C library. However, gcc is intimately linked to the C library for normal compiles.
Then there is the code. It is not written for Linux. It is written for a bare-metal application. You need to load and run the code from the Raspberry-Pi boot loader (berryboot?) without Linux.
You can use the ARM Linux compiler to create code for a bare-metal application. However, it is probably easier for you to find a newlib compiler that is targeted for the Raspberry Pi. You can search for one on the web or try to build one yourself.
See: How to build gcc for Raspberry Pi and Bare-metal gcc.
Is it possible to use the stock (non-apple) version of g++ on Mac OSX 10.7? I want to be able to use the stock g++ without running a virtual linux box on my mac. The reason I want to do this is because apple's version of g++ doesn't warn you when there are unused variables and etc. I'm doing some assessed C++ problems in my numerical methods course and I want to make sure I'm not making any mistakes.
It was suggested I make a symbolic link to a linux version of g++ for compiling the code for the assessments. How do I go about doing that?
Thanks
A linux version of the compiler will not work on what is (essentially) a bsd port.
Are you sure that the current version of g++ cannot warn on the conditions you expect?
Finally, if #2 is true, there is nothing stopping you from getting another version of g++ (compiled for MacOSX) that doesn't have this issue.
A binary for g++ for Linux won't run on MacOSX.
You could compile GCC from its source code; use the latest release i.e. 4.6.2. But that requires some work. Be sure to follow the installation instructions, in particular care about dependencies (like PPL & Cloog) and configure (appropriately) and compile in a build tree outside of the source tree.