Cross Compile Toolchain (for building outside TC)

[nim108]

So this is probably asking for a lot but here it goes anyway:

I could be wrong about this since I haven't used TC since 4.x but one of the biggest limitations of TC I see is that there is no cross compile toolchain externally available to build TC or TC apps/extensions outside of a TC environment. This means you must build in TC. Even scripts exist to build TC in its entirety from scratch, but again, it has to be done within TC. Obviously, a build/dev environment like TC is not ideal (it was a big PITA for me to compile my custom libs and kernel modules in there) as one would probably use a more complete distro like Ubuntu/Fedora/etc. Nearly all embedded platforms provide this on some level (the most infamous being the arm-linux-gnueabihf toolchain for ARM platforms). I just think it's a lot easier if those tools are provided as a sysroot so that we can easily cross compile TC apps in a different environment. It makes it a lot easier to code too because a lot of IDEs give you the option of specifying a sysroot.

One major use case I have at work is automating builds and for this, we use Vagrant (and Packer). We have no problems using Linux Mint as the dev environment for Buildroot + RPi and even cross compiling for Windows using Mingw (through MXE). TC however presents a problem ... obviously there is no TC "box" available so there is no easy way to automate anything. That means going through a whole formal process to document another build environment.

Not complaining, I love TC because it does all the hard work for you and still contains it within a 10 MB kernel/initrd which is incredible. I'm just asking if this is something the devs would consider (releasing a built sysroot as a tar.xz as others do). Thanks. Perhaps in the future you guys can take a look at the crosstool-ng project too; it takes a lot of work away from generating your own toolchain, just a suggestion.

[Juanito]

Obviously, a build/dev environment like TC is not ideal...

Why "obviously"?

I haven't seen that tc is any more or less difficult to compile in than other linux distros.

[curaga]

Cross-compiling always comes with gotchas, I would ask why would you do that if you don't have to?

Even on ARM platforms, once they became fast enough, all distros prefer native compilation, see Debian/Fedora/Ubuntu and so on. It's much easier and compatible with more packages.

If a separate box is unviable, why not use a VM or a chroot?

Obviously, a build/dev environment like TC is not ideal (it was a big PITA for me to compile my custom libs and kernel modules in there) as one would probably use a more complete distro like Ubuntu/Fedora/etc.

I disagree, I can do everything I want in TC... I find compiling anything to be just as easy as anywhere else. I see you mention IDEs, which could be the point - for someone stuck in Eclipse etc. who don't know better, building without the IDE would indeed be hard.

[bmarkus]

Regarding ARM, I'm cross compiling only the kernel for piCore, everything is native. Spent few weeks with cross compilation in the beginning but it always failed for some reason so finally I dropped. Now with 4 CPU cores and 1GB RAM it is smooth to make a native build even of larger packages like Qt, mono, etc.

BTW, Raspbian was always built on ARM machine. Not Raspberry Pi, but on a more powerful ARM system.

Cross compilation also makes your dev procedure more complicated and time consuming, slowing you down and generating unnecessary task and bugs to fix. It is useful only in the very beginning to port to a new architecture or when target system has limited resources.

In TC you can setup the same dev environment as on any other LINUX system.

[nim108]

Obviously, a build/dev environment like TC is not ideal...

Why "obviously"?

I haven't seen that tc is any more or less difficult to compile in than other linux distros.

All I meant is that users are already used to their existing Linux distro while TC has its own quirks you need to learn (persistency, extensions, all the custom scripts TC has, etc.). I do agree, if you're running TC natively, it's just as easy to compile in. However, if you're running it in a VM, as is my case, it's difficult to get working correctly. For example, many of my custom libs are in my host Mint environment ... to get them into a TC VM to compile there, because VMWare Tools doesn't install in it, I can't use shared folders or drag and drop. Essentially, I have to mount a USB stick in Mint, copy what I need off, unmount, mount it in TC, and copy them back off there. Then obviously it doesn't scale the resolution properly without the 3D accelerated VMware graphics driver.

Cross-compiling always comes with gotchas, I would ask why would you do that if you don't have to?

Even on ARM platforms, once they became fast enough, all distros prefer native compilation, see Debian/Fedora/Ubuntu and so on. It's much easier and compatible with more packages.

If a separate box is unviable, why not use a VM or a chroot?

Obviously, a build/dev environment like TC is not ideal (it was a big PITA for me to compile my custom libs and kernel modules in there) as one would probably use a more complete distro like Ubuntu/Fedora/etc.

I disagree, I can do everything I want in TC... I find compiling anything to be just as easy as anywhere else. I see you mention IDEs, which could be the point - for someone stuck in Eclipse etc. who don't know better, building without the IDE would indeed be hard.

As mentioned above, I am using a VM, but that presents its own issues. I mean even now I can do everything I want in TC ... but there is a steep learning curve and it makes nothing easy. I'm just trying to get more people to use this since it's just awesome for runtime, I've just had issues automating stuff for development. I agree, distros prefer native compilation and it generally results in trouble-free compiles, but the option to cross-compile is there for most toolchains. Otherwise, imagine having to compile for RPi or the BBB natively on themselves without a cross compile toolchain (this is an extreme example but just trying to prove a point).

Regarding ARM, I'm cross compiling only the kernel for piCore, everything is native. Spent few weeks with cross compilation in the beginning but it always failed for some reason so finally I dropped. Now with 4 CPU cores and 1GB RAM it is smooth to make a native build even of larger packages like Qt, mono, etc.

BTW, Raspbian was always built on ARM machine. Not Raspberry Pi, but on a more powerful ARM system.

Cross compilation also makes your dev procedure more complicated and time consuming, slowing you down and generating unnecessary task and bugs to fix. It is useful only in the very beginning to port to a new architecture or when target system has limited resources.

In TC you can setup the same dev environment as on any other LINUX system.

Thanks bmarkus. I appreciate your comments as you've already tested this scenario somewhat with the RPi. I don't necessarily agree that cross compilation makes the dev procedure more complicated ... it's quite the opposite for us: now we can use one environment to build everything. I compile for all these platforms just using a 64-bit version of Mint: RPi using Buildroot and the arm gnueabihf toolchain, BBB with same setup (you can easily use Yocto here instead if you want too), i686 platforms using an i686 glibc nptl crosstool-ng toolchain, Windows machine using MXE and the Mingw toolchain, and much more.

I agree with all you guys that natively, TC is just as good as anything else. In a VM and when it comes to automating tasks and builds, it becomes more challenging and that's the only reason I asked about a toolchain. Then you wouldn't have to waste time setting up TC on its own with compiletc, linux-kernel-sources-env, autotools, autoconf, etc. etc. It also makes offline builds so much easier since TC's main mechanism for installing apps is the AppBrowser, which assumes you are connected. Anyway, just thought it was worth asking, no biggie Thanks for the replies/feedback.

[curaga]

Why not move files using the network? SSH in particular is likely already running on the host, so you can use scp in the guest (dropbear.tcz or openssh.tcz).

For offline builds, you'd typically store the entire tce directory once when connected, then load it later.