It's for the main reason (mucking up the host) that I avoid cross-compiles like the plague. Much easier to farm off the compilation to specific boxes. There's another good reason: maintenance of the cross inevitably suffers from bitrot. It's rather ironic that I find myself this week attempting cross-compiles because I let bitrot go on too long. My DNS server is still on "jessie". I'm trying to have everything "bookworm". I don't have the time (in long enough uninterrupted periods) to upgrade the DNS server. It would be rather nice if an app of mine 'sdv' could be updated on the DNS server (pi07). I'll describe the journey so far..
I tried my current "arm-linux-gnueabihf" on my PC. I'm gonna paste things verbatim for brevity. It is..The 64bit cross compiler (henceforth "xgcc") version is..As was the 32bit version but I've ended up I've ended up with this....because the DNS server is..No matter what fudges (copying libs across and using LD_LIBRARY_PATH) I tried, nothing was stable. You know things have gone pear-shaped when even 'ldd' is yielding "Illegal Instruction" on pi07. Essentially a gcc "ABI" problem. I messed around trying different gcc versions in the hope of finding one with an overlap but it wasn't to be. Long gone is the idea of using gcc-14.2.0 to target pi07. Nothing for it to go full monty and build a gcc 4.9.2. That didn't happen (reasons I've forgotten already) but I did persuade gcc-4.9.4 to work. Good enough I hope for "ABI" purposes. At least now pi07 can run "Hello C++ World" without copying across libs. The build is currently using..Current state of affairs is I have 32bit arm xgcc 4.9.4 on my PC. Native 4.9.4 on both my 64bit "bookworm" and "bullseye" rpi.
So happens, gcc-4.9.4 won't build. The lowest gcc that can be built on modern linux (PC and rpi) appears to be gcc-8.4.0 so I built that. Then I used 8.4.0 to bootstrap compile 4.9.4. I had to patch the 4.9.4 source. Actually a hack: I've yet to figure out how to perform a generic patch (I likely won't put time into that if what I've got can compile 'sdv'). Repeat using the xgcc 4.9.4. Don't need 8.4.0 any more. Almost forgot! I had to stuff in my own compilers 'sdcc'" and 'sdcx' for CC and CXX respectively. Those are just stubs which force "-std=" options into the build.
I made an attempt at cross compiling 'sdv' on the PC. Had to add in some conditionals in my generic "sdlib" (all my apps use it) to lose some "pragma"'s which 4.9.4 doesn't understand. Then the bombshell hit: mysql. It's where I'm at currently. I'm going to have to cross compile mariadb because "sdlib" requires mysql (actually mariadb now). Traditionally I build everything (mariadb 10.6.5) and use a "mysql" symlink. Turns out 10.6.5 has issues on rpi. Not insurmountable but 11.4.2 compiles cleanly. Everything is on hold while I have all the relevant rpi build 11.4.2 and test nothing breaks when I change the "mysql" symlink to point at it.
The 'sdv' app only needs the client. Thanks "google" for making mariadb cmake option "-DWITHOUT_SERVER=on" nigh on impossible to find. Now it (cross mariadb client) will have to wait (for more uninterrupted time). It'll be a test some non-trivial xgcc output works.
Contrast with the above, an attempt to build an rpi 64bit -> 32bit xgcc when they're both bookworm, will be as painless as it can be for cross compiles. Still not trivial. Are you experienced in compiling gcc natively? The attached script will help with that.It will compile gcc-14.2.0 and install to /tmp/ (needs ~2G in /tmp or edit PFX). See the "~~~" hints. Remove them once you've verified it works.
..builds a full, stage 3 compiler. The "go" stuff code is valid and works but none-code will be out of date. The "README.md" etc is likely drivel.
Typically you install "go" in some path then put symbolic links to it globally. My scripts have..The "F_GO_TMPFS" variable speeds up builds (uses tmpfs). Comment it out to have it use disk proper. Hint: "./go.1420 del all".
I'm figuring if my 4.9.4 (64bit bookworm -> 32bit jessie) actually turns out to generate viable code, then my (very much more complicated) xgcc script might be useful - but I'm not massaging it to leave out "go". I invented my "go" before google even thought of it btw.
Code:
admin@pi07:~ $ uname -aLinux pi07 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/LinuxCode:
: ${BU_PKG:="binutils"}: ${BU_VER:="2.26.1"}: ${LK_PKG:="linux"}: ${LK_VER:="4.19.66"}: ${GC_PKG:="gcc"}: ${GC_VER:="14.2.0"}: ${LC_PKG:="glibc"}: ${LC_VER:="2.28"}Code:
foo@sdu:~/usr/src/pi/xgcc$ /usr/local/RPI/aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc -vUsing built-in specs.COLLECT_GCC=/usr/local/RPI/aarch64-linux-gnu/bin/aarch64-linux-gnu-gccCOLLECT_LTO_WRAPPER=/usr/local/RPI/aarch64-linux-gnu/libexec/gcc/aarch64-linux-gnu/14.2.0/lto-wrapperTarget: aarch64-linux-gnuConfigured with: ../gcc-14.2.0/configure --prefix=/usr/local/RPI/aarch64-linux-gnu --enable-languages=c,c++ --disable-multilib --target=aarch64-linux-gnu --with-headers=/usr/local/RPI/aarch64-linux-gnu/aarch64-linux-gnu/include/linuxThread model: posixSupported LTO compression algorithms: zlibgcc version 14.2.0 (GCC) Code:
foo@sdu:~/usr/src/pi/xgcc$ /usr/local/RPI/arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc -vUsing built-in specs.COLLECT_GCC=/usr/local/RPI/arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gccCOLLECT_LTO_WRAPPER=/usr/local/RPI/arm-linux-gnueabihf/libexec/gcc/arm-linux-gnueabihf/4.9.4/lto-wrapperTarget: arm-linux-gnueabihfConfigured with: ../gcc-4.9.4/configure --prefix=/usr/local/RPI/arm-linux-gnueabihf --enable-languages=c,c++ --disable-multilib --target=arm-linux-gnueabihf --disable-default-pie --with-arch=armv6 --with-fpu=vfp --with-float=hard --with-headers=/usr/local/RPI/arm-linux-gnueabihf/arm-linux-gnueabihf/include/linuxThread model: posixgcc version 4.9.4 (GCC)Code:
admin@pi07:~ $ gcc -vUsing built-in specs.COLLECT_GCC=gccCOLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.9/lto-wrapperTarget: arm-linux-gnueabihfConfigured with: ../src/configure -v --with-pkgversion='Raspbian 4.9.2-10+deb8u2' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihfThread model: posixgcc version 4.9.2 (Raspbian 4.9.2-10+deb8u2)Code:
: ${BU_PKG:="binutils"}: ${BU_VER:="2.26.1"}: ${LK_PKG:="linux"}: ${LK_VER:="4.9.35"}: ${GC_PKG:="gcc"}: ${GC_VER:="4.9.4"}: ${LC_PKG:="glibc"}: ${LC_VER:="2.22"}So happens, gcc-4.9.4 won't build. The lowest gcc that can be built on modern linux (PC and rpi) appears to be gcc-8.4.0 so I built that. Then I used 8.4.0 to bootstrap compile 4.9.4. I had to patch the 4.9.4 source. Actually a hack: I've yet to figure out how to perform a generic patch (I likely won't put time into that if what I've got can compile 'sdv'). Repeat using the xgcc 4.9.4. Don't need 8.4.0 any more. Almost forgot! I had to stuff in my own compilers 'sdcc'" and 'sdcx' for CC and CXX respectively. Those are just stubs which force "-std=" options into the build.
I made an attempt at cross compiling 'sdv' on the PC. Had to add in some conditionals in my generic "sdlib" (all my apps use it) to lose some "pragma"'s which 4.9.4 doesn't understand. Then the bombshell hit: mysql. It's where I'm at currently. I'm going to have to cross compile mariadb because "sdlib" requires mysql (actually mariadb now). Traditionally I build everything (mariadb 10.6.5) and use a "mysql" symlink. Turns out 10.6.5 has issues on rpi. Not insurmountable but 11.4.2 compiles cleanly. Everything is on hold while I have all the relevant rpi build 11.4.2 and test nothing breaks when I change the "mysql" symlink to point at it.
The 'sdv' app only needs the client. Thanks "google" for making mariadb cmake option "-DWITHOUT_SERVER=on" nigh on impossible to find. Now it (cross mariadb client) will have to wait (for more uninterrupted time). It'll be a test some non-trivial xgcc output works.
Contrast with the above, an attempt to build an rpi 64bit -> 32bit xgcc when they're both bookworm, will be as painless as it can be for cross compiles. Still not trivial. Are you experienced in compiling gcc natively? The attached script will help with that.
Code:
$ sudo apt-get install bc$ mkdir ~/T$ cd T$ git clone https://github.com/swampdawg/go$ #(unzip "go.1420" here)$ ./go.1420 qfinalCode:
$ ./go.1420 ntfinalTypically you install "go" in some path then put symbolic links to it globally. My scripts have..
Code:
GOSUB="/usr/local/sd/syschk/lib"Code:
foo@pi24:~ $ lc /usr/local/sd/syschk/libtotal 0lrwxrwxrwx 1 foo foo 29 Aug 24 10:19 f_go -> /home/foo/usr/src/git/go/f_golrwxrwxrwx 1 foo foo 30 Aug 24 10:19 f_tmp -> /home/foo/usr/src/git/go/f_tmplrwxrwxrwx 1 foo foo 33 Aug 24 10:19 f_tmpdir -> /home/foo/usr/src/git/go/f_tmpdirlrwxrwxrwx 1 foo foo 31 Aug 24 10:19 f_trap -> /home/foo/usr/src/git/go/f_traplrwxrwxrwx 1 foo foo 30 Aug 24 10:19 f_var -> /home/foo/usr/src/git/go/f_varI'm figuring if my 4.9.4 (64bit bookworm -> 32bit jessie) actually turns out to generate viable code, then my (very much more complicated) xgcc script might be useful - but I'm not massaging it to leave out "go". I invented my "go" before google even thought of it btw.
Statistics: Posted by swampdog — Sun Aug 25, 2024 11:31 pm