Host system for FC development

Thu Oct 25 03:59:36 UTC 2018

Hello FreeCalypso community,

As many of you know, I am a rather serious retrocomputist, and the
host system I use for FreeCalypso development is quite far from what
most of the younger generation expects as the norm.  The only Linux
distribution which I find somewhat tolerable is Slackware (all systemd
distros are absolutely intolerable to me, and even before systemd came
along I found Debian intolerable for some other reasons which I can no
longer remember clearly), and up until about a month ago I was running
Slackware release 13.37: I started using it in early 2013, but the
release itself dates from 2011.

The big current news in my life is that over the course of this past
month I was making a quite painful migration to a newer version of
Slackware (14.2 released in the summer of 2016), and I am now at a
point where this migration can be considered to be mostly complete.
For anyone else who may potentially be thinking about replicating my
development system setup, here are the issues I ran into and had to
fix:

1) I am a devoted K&R C programmer, and I principally refuse to change
my coding style to ANSI C.  In the case of FC host tools and other
programs which need to run under Linux as userspace apps, I write them
as if I were writing for 1980s big UNIX, and make absolutely minimal
use of "modern" Linux facilities only where absolutely necessary.  The
version of gcc that came with Slackware 13.37 (gcc-4.5.2) was happy to
compile my 1980s-style K&R C code without throwing up any warnings,
but the version that came with Slackware 14.2 (gcc-5.3.0) screams at
the top of its lungs about how much it dislikes my code - it still
compiles successfully in the end, but the amount of warning noise is
overwhelming and unacceptable to me.

My solution was to reverse-upgrade my native host gcc to version
4.5.4: reverse upgrade is my term for migrating to a version which is
chronologically older, but which I consider to be an upgrade because I
like it better than the chronologically newer one.  In order to not
disturb the new Slackware system or anything that may depend on or
prefer the new gcc (such as the Linux kernel build), I kept Slackware's
gcc-5.3.0 in /usr/bin/gcc, but I installed gcc-4.5.4 (native) under
--prefix=/usr/local/oldgcc, and when I work on FC host tools or other
software written in my taste, I do this:

PATH=/usr/local/bin:/usr/local/oldgcc/bin:/usr/bin:/bin:/opt/freecalypso/bin:/opt/freecalypso/gcc/bin

2) Newer versions of texinfo contain some kind of misfeature which
causes older versions of gcc (like our 4.5.4) to fail to build on
systems with this newer texinfo.  Because texinfo is such an
unimportant tool (at least for someone like me whose religion is the
Temple of Holy Vi as opposed to the Church of Emacs), I took the brute
force approach of reverse-upgrading it to texinfo-4.13a-i486-4.txz
(the package from Slackware 13.37) with Slackware's upgradepkg tool
which does not mind doing reverse upgrades.

3) When I tried to compile our gcc-built experimental Selenite fw
using the ARM7 gcc toolchain I had built back in 2013-08, I got this
lovely error:

error while loading shared libraries: libmpc.so.2: cannot open shared
object file: No such file or directory

The new Slackware has libmpc.so.3 (to which the basic unversioned
libmpc.so symlink points), but no libmpc.so.2 - so much for backward
compatibility with pre-existing binaries...  In any case, I had to
recompile our ARM7 gcc toolchain from source on this new Slackware.
I used my reverse-upgraded native gcc-4.5.4 to compile gcc-4.5.4 for
ARM7, and once texinfo was also reverse-upgraded to the good old
version, our ARM7 gcc toolchain built without a hitch.

4) Wine does not come bundled with Slackware, so I had to find an
unofficial Slackware package somewhere on the net and install it with
installpkg.  Fortunately I had saved the package file which I had
found and installed back in 2013 (wine-1.5.23-i486-1sg.txz), and it
installed without a hitch on this newer Slackware 14.2, thus I am
using the same Wine version as before, 1.5.23.  The Linux kernel is
now much newer (13.37 came with 2.6.37.6, 14.2 came with 4.4.14, and I
just switched to running 4.4.160 which I compiled myself), but I still
need to use the nowhine wrapper because plain unwrapped wine still
emits these obnoxious whines:

preloader: Warning: failed to reserve range 00010000-00110000

One takeaway for other aspiring FC developers is that a prebuilt ARM7
gcc toolchain may not be portable from one host system to another, as
my experience with missing libmpc.so.2 demonstrates, so folks need to
be prepared to build ARM7 gcc from source if they wish to play with
FC Selenite.  However, some folks may still wish to use prebuilt
packages that may be portable across a narrower range of host systems,
in which case I would like to have a standardized --prefix location
for this ARM7 gcc toolchain.

Back in 2017-05 our dear contributor Das Signal put out prebuilt i386
and x86_64 binary packages for our ARM7 gcc toolchain, and they were
built with --prefix=/opt/freecalypso.  However, my preference is to
use --prefix=/opt/freecalypso/gcc instead for the ARM7 gcc toolchain:
the rationale is that my style is very different from GNU, and as the
Mother of FreeCalypso I would like to retain full ownership of the
directory layout under /opt/freecalypso, with only me and not GNU
adding things in there.  For reference, this is how my /opt/freecalypso
directory looks:

$ ls -l /opt/freecalypso
total 44
drwxr-xr-x 2 hec users 4096 Oct 24 13:21 aud-fcdev3b
drwxr-xr-x 2 hec users 4096 Oct 24 13:21 aud-gtamodem
drwxr-xr-x 2 hec users 4096 Nov 29  2017 batteries
drwxr-xr-x 2 hec users 4096 Aug 11 13:52 bin
drwxr-xr-x 4 hec users 4096 Dec 30  2017 charging
drwxr-xr-x 8 hec users 4096 Oct 13 10:00 gcc
drwxr-xr-x 2 hec users 4096 Apr 25 10:28 helpfiles
drwxr-xr-x 3 hec users 4096 May 20  2017 include
drwxr-xr-x 2 hec users 4096 Apr 25 10:28 loadtools
drwxr-xr-x 4 hec users 4096 Jul 15  2017 rfcal
drwxr-xr-x 2 hec users 4096 Mar 17  2018 target-bin

As you can see, this directory layout looks absolutely nothing like
Linux FHS or GNU style, and instead we have the following:

aud-*: these directories appear if you install our optional
fc-audio-config package, and contain subtrees to be uploaded by
production line scripts into target device FFS under /aud via fc-fsio.

batteries and charging: these subtrees come from fc-battery-conf
(optional just like fc-audio-config) and are meant to be used with
fc-fsio write-battery-table and write-charging-config commands.

bin and include are the only subdirectories under /opt/freecalypso
which follow traditional UNIX directory layout; include was added so
that packages external to the core FC host tools package like
fc-rfcal-tools and freecalypso-ui-dev can use rvinterf headers.

helpfiles subdir contain help files for those FC host utilities which
implement a help command.

loadtools subdir contains hardware parameter files and init scripts
which underlie the all-important -h option to fc-loadtool, fc-iram and
fc-xram, collectively known as loadtools.

rfcal subdir only appears if you are doing RF calibration and install
fc-rfcal-tools, and some of the necessary config files under that
subdir you have to create yourself using your own RF knowledge specific
to your particular setup.

target-bin contains ARM7 target binaries used under the hood by
loadtools.

The basic minimal form of the /opt/freecalypso tree is populated when
you install FC host tools, but it is further enriched if and when you
install further add-ons (fc-audio-config, fc-battery-conf,
fc-rfcal-tools) which are more specialized and not required for all
users.  I expect to have more additions in the future: for example,
when we start using the Melody E1 mechanism in our planned FC Libre
Dumbphone, there will be a FreeCalypso ringtones package that will
install E1-format melody files somewhere under /opt/freecalyso, to be
subsequently uploaded into the actual phones via fc-fsio, initially at
production time and optionally by end users.

Given this quite elaborate assortment of FreeCalypso-specific stuff
under /opt/freecalypso under my design, I really dislike the idea of
having this main directory polluted by whatever GNU tools feel like
installing under their --prefix, hence I have created a new
/opt/freecalypso/gcc directory and I am now using it as the --prefix
for the ARM7 gcc toolchain:

$ ls -l /opt/freecalypso/gcc
total 24
drwxr-xr-x 6 hec users 4096 Oct 13 10:05 arm-elf
drwxr-xr-x 2 hec users 4096 Oct 13 10:06 bin
drwxr-xr-x 2 hec users 4096 Oct 13 10:00 include
drwxr-xr-x 3 hec users 4096 Oct 13 10:06 lib
drwxr-xr-x 3 hec users 4096 Oct 13 10:00 libexec
drwxr-xr-x 4 hec users 4096 Oct 13 09:52 share

So, what do others think?  For those who like the idea of a prebuilt
binary package with our ARM7 gcc toolchain, would DS or anyone else be
willing to produce a version with --prefix=/opt/freecalypso/gcc?  I
just tarred up and uploaded my version:

https://www.freecalypso.org/members/falcon/slackware/fc-arm7-gcc-slack14.2.tar.bz2

but I have no idea if it will work on any system other than mine,
hence someone else may need to build a different binary package for
more "modern" host systems.

Yes, I realize that having ARM7 gcc toolchain --prefix set to
/opt/freecalypso/gcc instead of just /opt/freecalypso means that you
now have to add not only /opt/freecalypso/bin to your PATH, but also
/opt/freecalypso/gcc/bin, but:

1) The ARM7 gcc toolchain is needed *only* for those who seek to
become FreeCalypso developers, it is *not* needed for end users - an
end user who needs to install a prebuilt firmware update or to tweak
something in FFS only needs our FC host tools and not any of our
compiler toolchains.  Furthermore, the ARM7 gcc toolchain is only
needed if you wish to play with our highly experimental Selenite fw or
if you need to recompile our essentially static target-utils
(loadagent etc) - compiling our production fw (Magnetite) does not
require ARM7 gcc and instead requires our Wine environment which is
another story altogether.

2) If you do need the ARM7 gcc toolchain and you wish to only have
/opt/freecalypso/bin in your PATH, you can go into /opt/freecalypso/bin
and do something like this:

$ ln -s ../gcc/bin/arm-elf-gcc .

and likewise for other arm-elf-* tools.

Hasta la Victoria, Siempre,
Mychaela aka The Mother