[Debian-lego-team] RCX packages (Was: Re: Bug#1091823: ITS: brickos)

[Matthew Sheets]

Update:

It seems that on the Ubuntu runner for the GitHub actions, C standard definitions are not very strictly enforced, so what builds there might not build on other systems.  I have gone back through and updated the GNU-Legacy-Toolchain, BrickOS-Bibo, and BrickEmu projects to adhere to the C or GNU standard that introduced the fewest issues (and then explicitly declaring that standard in the various CFLAGS settings), so hopefully they should be more reliably building on different systems now.

If I don't try to build a native version of GCC 3.4.6, with the latest commits on GNU-Legacy-Toolchain, BrickEmu, and BrickOS-Bibo, I can:
 * Build and the GCC toolchain (with languages C, C++, Objective C, Pascal, Fortran, and Java), including GDB and newlib, for h8300-hitachi-coff.  Notes and observations include the following:
  (1) In the src-combined folder, there is a configure script that sets up the configure scripts of the toolchain, plus an h8300-hitachi-coff-configure script that calls that configure script with the options typically used when building an h8300-hitachi-coff toolchain.
  (2) On openSUSE Tumbleweed, I encountered a scenario where "make" was trying to run *.m files through the C compiler instead of awk.  Locally only, I temporarily tweaked the SUFFIXES and .SUFFIXES in the binutils/gprof Makefile.am and Makefile.in to exclude ".m" suffixes.  Not sure if that might be an issue elsewhere (it is not on a local Ubuntu and the GitHub Ubuntu runner).
  (3) I tried removing the "git restore-mtime" action from the GitHub continuous integration action, but a new failure appeared when attempting to install binutils/bfd/doc/bfd.info.  I haven't yet been able to reproduce locally on either a local Ubuntu or openSUSE Tumbleweed (even tried deleting the bfd.info file to force it to regenerate), but I did previously install and run "git restore-mtime" shortly after I initially cloned the repository, so that might not have been the best test.
  (4) On install, there are four encoding errors reported in Pascal *.texi files, but they don't cause the install to fail:
    • en/authors.texi:331: encoding error at byte 0xf6
    • hr/gpc.texi:3: encoding error at byte 0xe8
    • es/gpcs.texi:3: encoding error at byte 0xe1
    • es/gpcs.texi:3: encoding error at byte 0xf3
    - In the above files, it appears to be choking on the characters ö, è, á, and ó

 * Build BrickEmu

 * Build BrickOS
   - Locally, I actually had to comment out the xs:Lisp support.  Even though it builds fine on the GitHub Ubuntu runner, the building of xs:Lisp native tools has been failing thus far regardless of which C standard I have tried applying.  The xs:Lisp support is supplemental, so this isn't a show-stopper level problem at the moment.

 * Run BrickEmu using the BrickOS firmware
   - Load and run a program (*.lx)
   - Load and run a program with debug symbols (*.a)


Apart from the quirks noted, for cross-compiler builds the GNU-Legacy-Toolchain repository might be close to ready.  I do have an in-progress multiarch-backport branch to try to help native-targeting builds run a little more smoothly in a multiarch world, plus I'd like to clean up some of the *.md files in the repository now that things seem to be stabilizing.  While patches aren't the only changes made in order to get things building, a list of the patches reviewed and applied is available in the README.md under the "patches" folder at the link below.
 • https://github.com/BrickBot/GNU-Legacy-Toolchain


> I can strip out some parts on import time if needed (like the
> LEGO firmwares for example).

If this perchance is a reference to the "rom.bin" file that was in the BrickEmu repository, BrickEmu actually includes its own ROM implementation that can be used.  If a user has a dump of their ROM, that can be used, but if not, the BrickEmu "make" process will uses the h8300-hitachi-coff toolchain to build that implementation.  As a build output, it shouldn't have been checked into version control, so I have removed it and added that filename to the .gitignore file, but running "make" will regenerate that "rom.bin" file.

For BrickEmu, a contribution by another user in the GitHub era was enabling a testing of BrickEmu as part of the GitHub continuous integration action, but I don't expect any licensing issues there.


Thank you,
Matthew