BaCon 4.x cross-compile problem in OE

A little while ago announced that all utilities written in BaCon had been removed from EasyOS:

BaCon dependency removed from OE — August 07, 2022

Then later on, it seemed the problem with compiling in OpenEmbedded had been solved:

The return of BaCon — August 14, 2022

However, it turns out that cross-compiling BaCon and apps written in BaCon, is not resolved. It was only fixed for the situation where was compiling on a x86_64 host OS, for a x86_64 target CPU.

Cross-compiling of BaCon, for a target-CPU different from host OS, does work with BaCon version 3.9.3, which was released a few years ago. So, I rolled-back BaCon to 3.9.3 in OE and did a compile in OE for 32-bit i686 target, the "-r4" build; the packages from which got released as EasyOS 32-bit version 4.3.5, announced yesterday:

EasyOS 32-bit i686 Dunfell-series version 4.3.5 — August 25, 2022

In that build, I returned to using various BaCon utilities, such as 'debdb2pupdb' and 'popup'. 'picscale' is also included, but not currently used.

BaCon 3.x series uses a cross-compiler-friendly technique for including library functions, by means of static library 'libbacon.a'. When compiling a utility written in BaCon, or compiling 'bacon.bac' itself, 'libbabcon.a' is created then statically linked to create the final executable.

This technique is as old as the hills and works fine.

BaCon 4.x changed to using 'flex' or 'lex' lexical analyzer, and did away with creating 'libbacon.a'. If I understand it correctly, this technique examines the source code and figures out what BaCon functions are required, and just compiles-in those.

So, an alternative to creating a 'libbacon.a' static library. The problem arises though, as the lexical analyzer creates a binary executable, named '<name>.bac.lex.exe', which it runs during the compile process.

In a cross-compile environment, all of the variables CC, CFLAGS, LDFLAGS, etc., are for building for the target CPU, hence '<name>.bac.lex.exe' will not run in the host OS.

It only worked when the target CPU was x86_64, and that fooled me, I thought BaCon compiling was fixed in OE. However, for a i686 target, '<name>.bac.lex.exe' failed to execute.

I have discussed this with Peter:

https://basic-converter.proboards.com/thread/948

Peter has proposed a fix is to leave 'flex' dependency out of the build. That means that every utility written in BaCon will have the entire library; so executables will be bigger.

No, I don't like that. As Peter is not prepared to implement a fix for this, I have suggested that down-the-track I might patch 'bacon.sh' and 'bacon.bac' to compile '<name>.bac.lex.c' to run on the host system. Looks easy to patch to do that.

For now though, OE is using BaCon 3.9.3, and all of the utilities compile and work, so there isn't any motivation to do anything more. Unless I want to take part in the new developments with the 4.x series.   

Tags: easy