Rebuild Compiler

Yes, you have to install the according 32-bit libraries with the package manager of your host PC. This is usually the libc and the zlib, maybe some more. Obviously python is also required in your case.

There are reasons for and against a toolchain built with buildroot:

For:

• The toolchain is always optimized for the root filesystem and board/CPU it is intended for.
• The toolchain can be individually configured and modified by the customer. For example he can decide which C library to use.
• The toolchain may be newer than an externally provided toolchain.

Against:

• A prebuilt external toolchain can be used immediately out-of-the-box without needing to download and compile buildroot first.
• Building the toolchain adds another 30 minutes or even more to the buildroot build process. And this has to be done over and over again after each "make clean".
• Checking a toolchain for proper results is rather difficult. There is no guarantee that the self-built toolchain will run trouble-free and will create proper code. When we provide an external toolchain, we know that it will work.
• Support of such a toolchain is rather complicated. We may look for errors in the application and maybe the problem is in the toolchain. When everybody uses the same toolchain, then also everybody will get the same results and we can rule out the toolchain if the behavior of some problem is the same here on our systems.
• When you are working with just one board/module, it is probably no big difference whether to use a self compiled toolchain or not. But when working with several different boards at the same time, like we at F&S do, if every board/module has its own toolchain, it gets really complicated to switch between all those toolchains. Just think of the PATH variable, environment settings and similar things. Here having one toolchain that works for all boards is a big advantage. And all these toolchains also require hard disk space. With each toolchain around 500 to 600 MB, this adds to a significant sum.
• Some settings depend on the type of toolchain you use. For example you can only compile some packages if the toolchain provides some specific features. If you compile your own toolchain, we can not be sure if our default configurations will still work. Even our prebuilt binaries may not work anymore. Or your own application fails to start when it is run on our prebuilt root filesystem or when running on our prebuilt kernel.
• The external toolchain may be newer than the supported buildroot. This is not the case right now, but it may be in the future. For example if we are stuck to some specific buildroot version for a while for some reason (like we were stuck to buildroot-2014.02 because newer versions also required a newer kernel version that we could not provide easily), then we may still update the toolchain in the meanwhile.

As you can see, having an own toolchain can get complicated in many places. Therefore in our view, the advantages of having a prebuilt external toolchain outweigh the advantages of a self-compiled toolchain. And for what its worth, if you really insist on having your own toolchain, then you are still free to do so by setting the according checkmarks in your buildroot configuration. But if you get in any trouble, then you are on your own.

Your F&S Support Team

How can I rebuild your toolchain for 64-bit? I would like to cross-compile on Windows 10 Ubuntu/bash and AFAIK, it cannot run 32-bit binaries.

Kind regards,
Hein Gustavsen
Miros AS

We do not support cross-compiling from Windows. You need a Linux machine (either native or as a virtual machine).

If you use a 64-bit Ubuntu (or any other Linux distibution), you can also run 32-bit programs if you install some 32-bit libraries. So the 32-bit toolchain has never been a problem in the past.

Your F&S Support Team

The Windows Subsystem for Linux (WSL) included in Windows 10 does run native 64-bit ELF binaries, but not 32-bit. I think a 64-bit version of your toolchain will run fine on Windows 10.

No it most probably won't run on Windows. For several reasons.

• The toolchain requires path names that are not available in Windows. The concept of drive names is completely unknown to the toolchain and backslashes that are required in Windows for path names also won't work.
• It requires that the system distinguishes between upper and lower case, which Windows does not, otherwise you can not compile Linux. As far as I know you can not even unpack the kernel tar file without getting an error on such a system.
• It needs quite a lot of libraries that are not part of the toolchain itself but need to be available on the system. But it is not possible to install those packages under Windows.
• Building Buildroot even fails if your Linux version is too old or too new. Having a non-Linux system will definitely not work. It misses too many tools and libraries and many configure scripts will fail.

And I am sure there will be many other problems. Just because Windows provides a basic bash shell now, it is not suddenly a full blown Linux system. Please forget the idea of cross-compiling things on Windows. It won't work.

Your F&S Support Team

Hi. I think you misunderstand how Windows Subsystem for Linux works. This is an Ubuntu 14.04 installation with a modified kernel that runs on top of Windows. It uses the Ubuntu 14.04 64-bit binaries (bash, etc.) but cannot run 32-bit ELF binary, which your compiler is. The file system is separate from Windows' own filesystem. It uses slashes (/) and is case sensitive. The windows drives are available in /mnt/c, /mnt/d, etc.

If you have a Windows 10 computer available, you should try yourself. Check out this information:
https://msdn.microsoft.com/en-us/commandline/wsl/about

I primary use Linux for cross compiling, but I also use Windows for development and could be handy to be able to cross compile on Windows Subsystem for Linux too.

Kind regards
Hein Gustavsen
Miros AS

OK, you are right, this might work. But I would wait until the whole system is more stable. In fact we are still using Windows 7 here. So no way to test it on Windows 10.

And to be true I still do not see the advantage. If you have your main compilation stuff in a Linux machine anyway, then I think it is easier to switch to the Linux Virtual Machine window and do work there instead of having a copy of all files in Windows, too, and do some compilation calls in Windows from from time to time. Doesn't this need duplicate data that may diverge?