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 _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community