1 of 1 people found this helpful
Here is how I make my case work,
I create a directory with the same path the configuration reports error, and copy the same source directory from my build machine over there.
Then I follow the guidance from Dietmar Re: Build debian Linux distribution for Galileo board with debootstrap
-m32 -fno-stack-protector -march=i586" ./configure
and some other configuration options needed for my package. This time configuration finished ok.
During make, it report a missing library, which also can be found in the work folder of my image built machine. So I move that library to /usr/lib folder of my Galileo board, and make again. This time it passed.
After make install, I have a working expect.
Still, would like to learn how other people can do it in a less messy way.
With embedded OSes you usually use the cross-compilation toolchain to compile the software for your target system (Galileo in this case) on your "big brother" machine, like PC or laptop.
For Galileo you can, as you already know, also create a Linux image, which would contain the tools right away, or use the cross-compilation. For the latter you'd need to generate the toolchain first - see the BSP Build Guide for instructions.
1 of 1 people found this helpful
Another way to build a new package is like this,
If the package only depend on standard package and library, it most likely will compile and build well in Galileo.
If the package does depend on some special package or library in Galileo BSP, and the built process fail. Just go ahead to rebuild and install the dependent package from scratch. That probably is the most clean way to resolve the issue. It just take more time.
I have tried it on expect and tcl (supported by Galileo BSP), rails and ruby (supported by Galileo BSP).
Or you can go the Yocto way and create a recipe for your package. Depending on specific circumstances, it may be much easier, than such a manual tinkering, because Yocto will compile it for you, install into the inmage and/or create an ipk package if you ask it to. And you'd be able to manage dependencies just by adding those into the recipe.
If I were just getting started, I would definitely go the customize a yocto build route.
However - once I had about 100 hours invested in customizing my Linux image, the appeal of starting over
has sort of faded. I fear I am stuck on 0.8.0 forever. On the other hand, my image does everything I want,
and new pieces are really easy to build from source.
My Galileo runs 24x7 with a web server, and I usually keep an ssh connection open for compiling my son's c++ homework. Makes a nice cross check on Visual Studio, which I tend to hate. But then some people like Windows 8 too.
I agree to make a recipe for a new package is the formal way to go, however I am not familiar with the whole environment well enough to make one yet.
In the mean time, it make sense for me to understand some basic questions first.
For example, with the toolchain method one can compile and build a new package faster and smoothly, however the question is how to install the package properly. I probe around the build environment more, and find some more information and there are some way might work.
1. an intermediate folder for target system root is under tmp/sysroots/clanton of the build directory, however one probably can't just make install DESTDIR=PATH-TO-BUILD-DIR/tmp/sysroots/clanton because when bitbake build image, it probably will clean it up.
2. so I try to mount the image-full-clanton.ext3 image on some temporary directory, so that I can install package there. This probably will work.
3. to make the new package usable by later packages, one can make one extra "make install" into the place toolchain installed its target system root, by default /opt/clanton-full/1.4.2/sysroots/i586-poky-linux
By the way, talk about toolchain, it probably work better with qemu. It will be very handy to have a virtual machine like qemui586.