OpenEmbedded Morty

Last week I spent a few days trying to use OpenADK, tried all kinds of targets and 32-bit and 64-bit hosts, simple basic configurations, always failures. I had the same experience when I tried it early 2016.
Strangely though, the project is active, so some people must be having success. It would have to be for very specific config and host system, details that are not provided.

So, I have moved on to OpenEmbedded. I wrote about this back in June 2016. It is one that does work. In fact, it is the only cross-compiler toolchain/sdk builder thingy that does work. My experience with OpenADK, Crosstool-NG and T2 is that they are all broken.

Here is my June 2016 blog post on OpenEmbedded:

And Yocto, which uses OpenEmbedded:

At that time, the stable release was named "Krogoth". It is now "Morty". See release notes:

I want to create a new light-weight pup compiled from source, like I did with Quirky April, and earlier on there was Wary and Racy Puppy. These were built from packages compiled in T2. Unfortunately, T2 has become increasingly broken, and there is only one guy maintaining it.

So, there is only one choice left, OpenEmbedded. I don't know what extra functionality Yocto will bring to the table, so decided to stay with OE.
Right now, doing a target "core-image-sato-dev" build (for machine "qemux86-64", using glibc):

What I want to do is create a bunch of binary packages, that I can then import into woofQ and build a new Quirky.
I suppose it needs a name, so how about "OpenPup"? -- just did a search, can't find that name used anywhere.

Anyway, the OE build is chugging away right now. From prior experience, I have a high confidence that it will succeed.


OpenADK has target gcc   Posted on 11 Apr 2017, 20:45 by admin
Correction, OpenADK has "Development appliance" option in the configuration, which compiles gcc, etc., in th target machine.

Native toolchain?   Posted on 11 Apr 2017, 10:11 by admin
It has completed, however, the resultant image does not have what I expected. See here:

Image with Sato for development work. It includes everything within core-image-sato plus a native toolchain, application development and testing libraries, profiling and debug symbols. understanding of "native toolchain" is different from what they mean. My understanding is that it would be a toolchain that will run in the target machine, not a cross-compiling toolchain.

It seems then, that OE/Yocto is not much better than Buildroot. What it does have over Buildroot is that it creates individual binary packages. Also has a much bigger selection of packages.

I guess, what it comes down to is that none of these tools are real "distribution builders". Exception is T2, if only I can get it to work.

Host is Quirky 8.0 x86_64   Posted on 10 Apr 2017, 19:47 by admin
The above post and links explain how I set things up. For the record, I am running Quirky 8.0 x86_64. This is Quirky built with Ubuntu Xenial Xerus 16.04 binary DEBs.
It is not the latest release, which is 8.1.6. I just happen to have a 8.0 installation on a USB stick, that I have been booting on my main laptop.

So, can add this as a compatible host distro for OE and Yocto.

ARM also   Posted on 10 Apr 2017, 19:31 by admin
Oh yeah, I want the builder to work for x86, x86_64, armv7 and armv8 target CPUs. Which narrows it down to OE/Yocto.

There is of course LFS, however, that is a very tedious manual method, and is only for x86 and x86_64.

compile in target   Posted on 10 Apr 2017, 19:26 by admin
One thing I should qualify. I want to build a target system with all dev tools, so could for example become a chrootable rootfs in the target machine, that can compile packages.
This rules out all the cross-compiler-toolchain-only builders. Which I think includes Crosstool-NG. Definitely excludes Buildroot.

Ideally, I want the tool to create binary packages of each package, which narrows it right down. Well, T2 or OE/Yocto.