gcc toolchain

I think there should be a developer section in the forum.

Something that would have sections like the following:

1: gcc toolchain

2: gcc on Raspberry Pi

3: C and C++ Programming for Raspberry Pi

4: C and C++ Programming on Raspberry Pi

5: Assembler programming

gcc toolchain would be for those building cross-compilers for computers running Mac OS X, Linux or Windows.

'gcc forum' would be for those installing those toolchains.

'C and C++ Programming for Raspberry Pi' would be for those who cross-compile C and C++ on a different platform and then program the device that way.

'C and C++ Programming on Raspberry Pi' would be for those, who are using Linux on Raspberry Pi and a native gcc compiler.

I think there will be a need for making a difference between 'on' and 'for'. Maybe I didn't choose the best words for distinguishing between the two, but I can imagine how many people who would be interested in the one, and not the other.

'for' would be programming the Raspberry Pi as a microcontroller.

'on' would be programming the Raspberry Pi as a computer (running Linux).

While I'm at it... I'd be interested in a toolchain for 'Mac OS X' - is there already a gcc which is configured for Raspberry Pi ?

I am using crosstools-ng to build a cross compiler toolchain. There are also prebuilt cross toolchains (there is a softfloat and hardfloat) in the raspberrypi github.

I set crosstools to experimental so I could pull in gcc 4.5 for both hardfloat and vfp. I'll probably roll a small embedded environment from scratch with bsd style init, busybox etc. Then perhaps add Qt and qmlviewer for playing with graphics.

At the moment I am just using scratchbox2 to build a few things and run (using qemu) until I can get some real hardware.

I don't see any need for X, web browsers etc. for my use. If I want to do something along those lines I will just grab the foundations supported distro.

There is lots of info about ABIs, compiler settings, cross compilation etc spread all over the forums already, you just have to go searching. It would be nice to have a c/c++ programming forum. It has also been suggested on raspberrypiforums.com.

For OSX, choose your cross building method (either one of the semi-automated scripts, or the download-compile-install route) and go for it. I was going to build a package containing everything, but couldn"t be bothered in the end - it"s as much work if not more than simply installing...

Googling for "gcc cross compiler build" should help

Simon

Hey, thank you both!

The reason I started this thread, was that when I searched this forum for "toolchain", I got no results, so I thought that nothing was there...

Someone once told me to never use crosstools (I don't really know why), so I started rolling my own build scripts. That's a long road.

I just found out that ARM is now offering (an official, I guess) ARM gcc:

https://launchpad.net/gcc-arm-embedded

http://elinux.org/RPi_Kernel_Compilation describes how to get a toolchain that can directly be used to compile the kernel or additional modules for the R-Pi. In Debian, the packages can be accessed by dropping…

deb http://www.emdebian.org/debian/ squeeze main

…to /etc/apt/sources.list (perhaps adjust the squeeze for your purposes). However, for user-space compilation things are a bit trickier, eg. you may need to have various libraries installed, and especially if you"re linking statically, those binaries must be ARM.

The following is IMO a very neat way to access the toolchain directly using emulation, but no need to start the operating system:

$ wget http://downloads.raspberrypi.o.....2-2012.zip

$ unzip debian6-17-02-2012.zip

$ sudo su

# apt-get install kpartx qemu binfmt-support qemu-user qemu-user-static

# kpartx -a debian6-17-02-2012/debian6-17-02-2012.img

# mount /dev/mapper/loop0p2 /mnt

# cp /usr/bin/qemu-arm-static /mnt/usr/bin

# cp /etc/resolv.conf /mnt/etc/resolv.conf

# mount -o bind /dev /mnt/dev

# mount -o bind /proc /mnt/proc

# mount -o bind /sys /mnt/sys

# chroot /mnt

… and use GCC, Apt, etc. directly Later you can unmount and even dd the image directly to your sd-card! Alternatively you can just copy all the partition contents to a local directory and chroot there in the same way. Remember to adjust your /etc/apt/sources.list to your nearest mirror.

To exit:

# exit

# umount /mnt/dev

# umount /mnt/proc

# umount /mnt/sys

# umount /mnt

# kpartx -d debian6-17-02-2012/debian6-17-02-2012.img

Note that this way you can even compile a new R-Pi kernel or modules in the chroot, forget about all the cross compilation stuff. No need to install a cross compiler outside the chroot. However, compilation is going to be slower since the gcc needs to be emulated, but unless you're compiling something huge, it doesn't matter. Unless you have an ancient desktop.

BR,

Jaakko

Here's an eLinux.org wiki page for gcc ARM cross-compilers, originally created for BeagleBoard: http://www.elinux.org/ARMCompilers

I've successfully used the CodeSourcery version of gcc for BeagleBoard under both Windows and GNU/Linux on x86 PCs.  The command line version of the tools is free.  CodeSourcery ought to work for RasPi provided that you set the ARM architecture (ARMv6) and processor version (ARM11) correctly and use the EABI that's compatible with your libraries.

For my own RasPi development, I'm planning to use native gcc on the RasPi itself.  Native gcc should come with any of the supported distros.  However, if you are doing a very large build you may be better off doing it on a PC.

Awesome inputs. (Note: I'm using a PowerPC based Mac, so there are a lot of Linux-shortcuts I can't take).

Regarding compiling on Raspi vs. compiling on a 'standard' xx THz desktop computer...

If you connect many Raspi's to via network, you can use distcc to distribute compiling. This is something that sounds attractive to me.

Does the Fedora Remix distro even include gcc ?

jaakkos said:

http://elinux.org/RPi_Kernel_Compilation describes how to get a toolchain that can directly be used to compile the kernel or additional modules for the R-Pi. In Debian, the packages can be accessed by dropping…

deb http://www.emdebian.org/debian/ squeeze main

…to /etc/apt/sources.list (perhaps adjust the squeeze for your purposes). However, for user-space compilation things are a bit trickier, eg. you may need to have various libraries installed, and especially if you"re linking statically, those binaries must be ARM.

The following is IMO a very neat way to access the toolchain directly using emulation, but no need to start the operating system:

$ wget http://downloads.raspberrypi.o.....2-2012.zip

$ unzip debian6-17-02-2012.zip

$ sudo su

# apt-get install kpartx qemu binfmt-support qemu-user qemu-user-static

# kpartx -a debian6-17-02-2012/debian6-17-02-2012.img

# mount /dev/mapper/loop0p2 /mnt

# cp /usr/bin/qemu-arm-static /mnt/usr/bin

# cp /etc/resolv.conf /mnt/etc/resolv.conf

# mount -o bind /dev /mnt/dev

# mount -o bind /proc /mnt/proc

# mount -o bind /sys /mnt/sys

# chroot /mnt

… and use GCC, Apt, etc. directly Later you can unmount and even dd the image directly to your sd-card! Alternatively you can just copy all the partition contents to a local directory and chroot there in the same way. Remember to adjust your /etc/apt/sources.list to your nearest mirror.

To exit:

# exit

# umount /mnt/dev

# umount /mnt/proc

# umount /mnt/sys

# umount /mnt

# kpartx -d debian6-17-02-2012/debian6-17-02-2012.img

Note that this way you can even compile a new R-Pi kernel or modules in the chroot, forget about all the cross compilation stuff. No need to install a cross compiler outside the chroot. However, compilation is going to be slower since the gcc needs to be emulated, but unless you"re compiling something huge, it doesn"t matter. Unless you have an ancient desktop.

BR,

Jaakko

This!

This explains why i want a Raspi. So i can try to understand what this post means and actually do what i says.

Dinosaur said:

jaakkos said:

...

This!

This explains why i want a Raspi. So i can try to understand what this post means and actually do what i says.

Well, I should've been less cryptic about it anyway. The point is, you can use the ARM root filesystem without actually starting the OS. Perhaps the most interesting command there is 'chroot'. This tells your command interpreter (in the Linux terminal that you have open) to think that suddenly the root file system is located somewhere else, and this can be the Raspberry Pi filesystem. This also means, in your terminal, you are restricted to the Raspberry Pi filesystem until you finally say 'exit'. We still need QEMU because you must be able to run binaries when you are inside.

The disk image distributed by R-Pi has, as expected, a complete disk layout with an msdos partition table, just like countless physical PC disks out there. In Linux these partitions described in the image can be accessed much like any other, real disk partition that is present on your computer. 'kpartx -a' is the magic to do this: it creates 'block devices' from the disk image you specify, and these devices can then be mounted just like any other disk device on your computer. Devices created like this are called 'loopback devices'.

After 'kpartx', the only thing you need is 'mount', after which you can see the guts of the root filesystem. The device you want to mount is /dev/mapper/loop0p2. 'dev' is the Linux directory for all kind of device files, also block devices. 'mapper' refers to the device mapper subsystem of Linux that manages special devices, such as loopback (like ours) or encrypted devices. 'loop0p2' is a node created by 'kpartx'. 'loop0' refers to the image file, and 'p2' means the second partition (root filesystem - first partition is boot).

Now, if you wanted to get rid of this loop device magic, after 'mount' you could use 'cp -pr' to recursively copy all the contents of /mnt to a directory on your local HDD. Then just replace '/mnt' in the further instructions with your directory name.

Next we need copying of /usr/bin/qemu-arm-static to the disk image. This enables us to emulate ARM binaries directly, which is required when we 'chroot' (read on). We also copy a file called 'resolv.conf'. This lets you access the Internet from the chroot (otherwise, the chroot environment cannot use name servers and you could only work with IP addresses!).

Then we have a couple 'mount -o bind' lines. These may not be necessary depending on what you plan to do, but some programs need these and you could say it lets the chroot environment access various hardware and information about your PC.

Finally, when you give the 'chroot' command, a command interpreter will be executed from the Raspberry Pi filesystem, and you're in. Now if you look around, you will find yourself isolated in the Raspberry Pi filesystem. You can directly run gcc or apt-get (to install more software). You don't need to do anything special to cross compile software, as everything you compile here will be properly built for Raspberry Pi.

Finally to exit the chroot jail, just type 'exit'.

(Mandatory note: do not use chroot as a security measure. While it seems like a jail, there are various ways to break out and access your real filesystem.)

In the Debian tutorial, Liam installs geany, a general purpose IDE. He uses it for Python programming, but I wanted C++ so… I issue the command:

apt-get install build-essential

..at the command prompt and it installs. "build-essential" is a so-called meta package (contains a list of packages to install) and it is required for kernal building IIRC; but it also includes gcc and g++ with all standard libraries which is why I always use it.

Since geany knows about C and C++ it's easy to start a project using one of those languages.

You wil need to use rpm instead of apt-get if you're going with the Fedora Remix. rpm is the package manager for Fedora I believe.

Now.. I just have to get over my vi withdrawl symptoms…

JonB said:

You wil need to use rpm instead of apt-get if you're going with the Fedora Remix. rpm is the package manager for Fedora I believe.

I think it's yum according to the documentation.

And some people wonder why those not familiar with Linux get so confused at time

I'm having trouble to get it to work under Debian Lenny.

There is no package called qemu-user and qemu-user-static. Continuing without it I get an error on the next step :  "server:~# kpartx -a debian6-17-02-2012/debian6-17-02-2012.img
/proc/misc: No entry for device-mapper found
Is device-mapper driver missing from kernel?
Failure to communicate with kernel device-mapper driver.
/proc/misc: No entry for device-mapper found
Is device-mapper driver missing from kernel?
Failure to communicate with kernel device-mapper driver.
Incompatible libdevmapper 1.02.27 (2008-06-25)(compat) and kernel driver
device mapper prerequisites not met
"
this is solved by "modprobe dm-mod"

To let kpartx work with ext4 I had to install lenny-backports Kernel ...

naicheben said:

I'm having trouble to get it to work under Debian Lenny.

There is no package called qemu-user and qemu-user-static. Continuing without it I get an error on the next step :  "server:~# kpartx -a debian6-17-02-2012/debian6-17-02-2012.img
/proc/misc: No entry for device-mapper found
Is device-mapper driver missing from kernel?
Failure to communicate with kernel device-mapper driver.
/proc/misc: No entry for device-mapper found
Is device-mapper driver missing from kernel?
Failure to communicate with kernel device-mapper driver.
Incompatible libdevmapper 1.02.27 (2008-06-25)(compat) and kernel driver
device mapper prerequisites not met
"
this is solved by "modprobe dm-mod"

To let kpartx work with ext4 I had to install lenny-backports Kernel …

Thanks, I need dm-crypt for encryption so had it loaded - adding modprobe to instructions.

Sorry, no proper qemu packages available unless you use Squeeze or later (Squeeze was released 2011-02-06), or (not an ancient) Ubuntu.

Indeed apt-get is only for Debian and Ubuntu, users of other distributions must use their own package manager.

BR,

Jaakko

uuuuhhhhhh Ubuntu ... no thanks ... I'll better try to dist-up to squeeze . Thank you.

Can't find the edit button any longer I favor Debian too. Perhaps it's time to upgrade anyway, good luck with your dist upgrade. I'm running 'testing'.

hehe, Thanks for keeping your fingers crossed, it woked for me. I'm already in chroot

Hm, I get many "qemu: Unsupported syscall: 341" . Is this ok to ignore them?

EDIT: "qemu: Unsupported syscall: 341
Can not write log, openpty() failed (/dev/pts not mounted?)
"

naicheben said:

Hm, I get many "qemu: Unsupported syscall: 341" . Is this ok to ignore them?

EDIT: "qemu: Unsupported syscall: 341
Can not write log, openpty() failed (/dev/pts not mounted?)
"

I actually forgot:

# mount -o loop /dev/pts /mnt/dev/pts

before 'chroot'. This will fix the pts problem (not critical) but I'm not getting the "unsupported syscall" error. Did you reboot after upgrading btw?

Yes I did reboot after upgrading. But I did not change the Kernel; I still have the backport-kernel .... should not hurt at all... I think it is 2.6.30 (installed because of no ext4 support in Lenny)

I'm just about to compile MMS (My Media System) can't wait for the RPi to come home back china ...

MMS uses SDL on X and not 3D ( no OpenGL-stuff needed like XBMC does)

hmm, ran into a new problem: no space left on device.

How can I tell qemu to give more harddisk space to the emutaled Debian?

Now it is 1.6G on rootfs, but I think I need at least 2G better 4G (closer to reality)

Ah, I had to install openbios-ppc and openbios-sparc from wheezey to get the squueze-backports to install

now I can resize the image with

qemu-img resize debian6-17-02-2012/debian6-17-02-2012.img 4G

to 4GByte disksize

naicheben said:

hmm, ran into a new problem: no space left on device.

How can I tell qemu to give more harddisk space to the emutaled Debian?

Now it is 1.6G on rootfs, but I think I need at least 2G better 4G (closer to reality)

Note that QEMU has actually nothing to do here, this is because the file system mounted over the loopback device gets full.

This is where you need to do one of two things:

1. 'cp -pr /mnt /your/preferred/directory' where /your/preferred/directory points to your hard disk. Then start using /your/preferred/directory for everything, you're backed by the full space available on the hard disk.

2. Resize the rootfs partition on the disk image. This way you can flash it directly to the SD card when you need it.

naicheben said:

hmm, ran into a new problem: no space left on device.

How can I tell qemu to give more harddisk space to the emutaled Debian?

Now it is 1.6G on rootfs, but I think I need at least 2G better 4G (closer to reality)

Note that QEMU has much nothing to do here, this is because the file system mounted over the loopback device gets full.

This is where you need to do one of two things:

1. 'cp -pr /mnt /your/preferred/directory' where /your/preferred/directory points to your hard disk. Then start using /your/preferred/directory for everything, you're backed by the full space available on the hard disk.

2. Resize the rootfs partition on the disk image. This way you can flash it directly to the SD card when you need it. However, you should set up swap space properly, which is not covered.

===========================================================>

root@thinkpad:/home/jvsalo/rasbpi/debian6-17-02-2012# truncate -s 8G debian6-17-02-2012.img

root@thinkpad:/home/jvsalo/rasbpi/debian6-17-02-2012# fdisk debian6-17-02-2012.img

Command (m for help): p

Disk debian6-17-02-2012.img: 8589 MB, 8589934592 bytes
4 heads, 32 sectors/track, 131072 cylinders, total 16777216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0000cded

Device Boot      Start         End      Blocks   Id  System
debian6-17-02-2012.img1            2048      155647       76800    c  W95 FAT32 (LBA)
debian6-17-02-2012.img2          157696     3414015     1628160   83  Linux
debian6-17-02-2012.img3         3416064     3807231      195584   82  Linux swap / Solaris

Command (m for help): d
Partition number (1-4): 3

Command (m for help): d
Partition number (1-4): 2

Command (m for help): n
Partition type:
p   primary (1 primary, 0 extended, 3 free)
e   extended
Select (default p): p
Partition number (1-4, default 2):
Using default value 2
First sector (155648-16777215, default 155648): 157696
Last sector, +sectors or +size{K,M,G} (157696-16777215, default 16777215):
Using default value 16777215

Command (m for help): w
The partition table has been altered!

Syncing disks.

root@thinkpad:/home/jvsalo/rasbpi/debian6-17-02-2012# kpartx -a debian6-17-02-2012.img

root@thinkpad:/home/jvsalo/rasbpi/debian6-17-02-2012# e2fsck -f /dev/mapper/loop0p2
e2fsck 1.42 (29-Nov-2011)
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix<y>? yes

Inode 202 was part of the orphaned inode list.  FIXED.

...

Inode 46822 was part of the orphaned inode list.  FIXED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found.  Create<y>? yes

Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/mapper/loop0p2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/mapper/loop0p2: 46830/101920 files (0.1% non-contiguous), 326333/407040 blocks

root@thinkpad:/home/jvsalo/rasbpi/debian6-17-02-2012# resize2fs /dev/mapper/loop0p2
resize2fs 1.42 (29-Nov-2011)
Resizing the filesystem on /dev/mapper/loop0p2 to 2077440 (4k) blocks.
The filesystem on /dev/mapper/loop0p2 is now 2077440 blocks long.

root@thinkpad:/home/jvsalo/rasbpi/debian6-17-02-2012# mount /dev/mapper/loop0p2 /mnt

root@thinkpad:/home/jvsalo/rasbpi/debian6-17-02-2012# df -h
Filesystem           Size  Used Avail Use% Mounted on
/dev/mapper/loop0p2  8.0G  1.4G  6.2G  18% /mnt

<===========================================================

I'm actually a bit worried about the fsck errors there. Nothing was copied to lost+found. This makes me ask, did they publish a messed up ext volume? Why?

Removed post. Forum software doing nasty things

Ah, thank you. It realy worked even though I had some trouble (as usual)

fdisk complained about DOS-compatability…

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
switch off the mode (command 'c') and change display units to
sectors (command 'u').

Command (m for help): p

Disk debian6-17-02-2012.img: 0 MB, 0 bytes
4 heads, 32 sectors/track, 0 cylinders
Units = cylinders of 128 * 512 = 65536 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0000cded

Device Boot      Start         End      Blocks   Id  System
debian6-17-02-2012.img1              17        1216       76800    c  W95 FAT32 (LBA)
Partition 1 has different physical/logical endings:
phys=(1023, 3, 32) logical=(1215, 3, 32)
debian6-17-02-2012.img2            1233       26672     1628160   83  Linux
Partition 2 has different physical/logical beginnings (non-Linux?):
phys=(1023, 3, 32) logical=(1232, 0, 1)
Partition 2 has different physical/logical endings:
phys=(1023, 3, 32) logical=(26671, 3, 32)
debian6-17-02-2012.img3           26689       29744      195584   82  Linux swap / Solaris
Partition 3 has different physical/logical beginnings (non-Linux?):
phys=(1023, 3, 32) logical=(26688, 0, 1)
Partition 3 has different physical/logical endings:
phys=(1023, 3, 32) logical=(29743, 3, 32)

Command (m for help): c
DOS Compatibility flag is not set

Command (m for help): u
Changing display/entry units to sectors

c-u solved it and I could change the size. Got the same errors on e2fsck.

EDIT: and had to change cylinder (x = expert mode and then c = cylinder = 131072)