What started as a spriling out of control build of SLiRP for User Model Linux (UML) I had so many issues with GCC 8, I figured I’d try v4 where I recall it building easily. Well that was. Fun.
Anywas I’m using Linux (Debian 10.5), and the build tools currently has me running GCC 8.3.0. Anyways a straight build introduces this fun:
../.././gcc/toplev.c: At top level:
../.././gcc/toplev.c:524:1: error: redefinition of ‘floor_log2’
floor_log2 (unsigned HOST_WIDE_INT x)
^~~~~~~~~~
In file included from ../.././gcc/toplev.c:59:
../.././gcc/toplev.h:175:1: note: previous definition of ‘floor_log2’ was here
floor_log2 (unsigned HOST_WIDE_INT x)
^~~~~~~~~~
../.././gcc/toplev.c:559:1: error: redefinition of ‘exact_log2’
exact_log2 (unsigned HOST_WIDE_INT x)
^~~~~~~~~~
In file included from ../.././gcc/toplev.c:59:
../.././gcc/toplev.h:181:1: note: previous definition of ‘exact_log2’ was here
exact_log2 (unsigned HOST_WIDE_INT x)
^~~~~~~~~~
make[2]: *** [Makefile:2064: toplev.o] Error 1
make[2]: Leaving directory '/home/jsteve/src/gcc-4.1.2/host-x86_64-unknown-linux-gnu/gcc'
make[1]: *** [Makefile:3905: all-gcc] Error 2
make[1]: Leaving directory '/home/jsteve/src/gcc-4.1.2'Ugh isn’t this fun. Well it turns out it’s largely from the confusion from how GCC now handles inline functions.
I’ve uploaded the patch here. It’s not great, I know but I got a working C compiler out of it, however I had to manually place xgcc/cc1/cpp from gcc-4.1.2/host-x86_64-unknown-linux-gnu/gcc
Naturally YMMV as always.
I did see further hints on this ‘gist‘ that also boils down to using GCC in 1989 mode for inlines:
gcc -fgnu89-inlineAnd also this ‘stack exchange‘ that mentions that toplev also has issues with the same inline issues. Naturally if you just define inline to nothing you’ll end up with two floor_log2 and exact_log2’s from libiberty. And both are different. Fun times ahead!
As for slirp, well I took the version from the Debian source project, and manually applied all the patches and I ended up not only having to manually create some missing headers, but after getting it to build it’d just crash immediately. Bummer.
I rebuilt it as a 32bit exe, and wow it ran just fine. Go figure. For anyone crazy enough to want to build it on it’s own, this patch take slirp-1.0.16 to a ’17’ with all the current Debian patches, and my sad patch, was what I did to get it to compile with GCC 4. Note you will want to save aside the ‘.p files’ which are the headers, as the configure will remove them and either save them as empty files, or files that don’t work. … Well at least they didn’t work for me!
The whole thing started as a ‘oh wow Linux is now in 5.1.0 release’ and I figured the easiest way to check it out was to use UML. I found this page with a quick ‘how to build and roll’ your own UML’s, although the SLiRP config is a bit off in the host, as it should be 10.0.2.15 for the UML kernel.
The new killer feature is UML can mount a directory as a filesystem so you don’t have to mess around like crazy to make disk images. It makes the experience more docker like, which I enjoy.
./linux root=/dev/root rootfstype=hostfs rootflags=/home/jsteve/linux/linux-5.1.17/uml-demo2 rw mem=64M init=/bin/shSo no I end up running this in the VM to kick off the required mounts and networking.
mount -t proc proc proc/
mount -t sysfs sys sys/
ifconfig eth0 10.0.2.15 netmask 255.255.255.0 broadcast 10.0.2.255
route add default gw 10.0.2.2
ping -c 2 10.0.2.2
Oh one thing worth pointing out is that 5.1.16 breaks 32bit compiles, you have to build 5.1.17 to get a 32bit kernel.
I should touch more on building UML but I’ve already sat on this for a week, and I’m too busy moving (yet again) to a smaller island. Hopefully a more peaceful one.
The 5.1.x kernel broke a few things apparently. Last one I knew about was that it broke the AppleTalk networking module (since fixed).
https://www.downtowndougbrown.com/2020/08/hacking-up-a-fix-for-the-broken-appletalk-kernel-module-in-linux-5-1-and-newer/
Just because it compiles without any errors doesn’t mean it’ll work folks 😛
Debian is pretty conservative still being on 4.x and it seems to have paid off. Ubuntu has since went to 5.x on a LTS.
I can’t say I’m surprised. Also a.out support seems to be totally hidden in the menu config I had to manually enable it, but even the 32bit kernel won’t run anything from my ancient tool chain. 1.0.9 runs them just fine.
So much for that stable backward support.
To build GCC 3 for ‘ns32k’ architecture I did a multi-step “downgrade”: build GCC 6 (or 7?) for x86 under modern GCC, build a GCC 3 for i386 with it and finally build cross GCC 3 for ‘ns32k’ target and ‘i386’ host. Fortunately modern linux kernel still runs i386 binaries well (requires 32-bit libraries).