Struggling to obtain the precious and unsupported SlackARM HardFloat port for armv6
 

I just went (twice) through the recipe discussed in the "Slackware ARM - FAQ - soft float and hard float" thread:

https://mindplusplus.wordpress.com/2...-raspberry-pi/

on a Pi2B running Slackware 14.2 SoftFloat, in order to get a softfp enabled armv6 compiler to further create HardFloat code and build a Slack ARM - current armv6-HardFloat port. The recipe needs some modifications, mainly downloading some missing source packages and there were some hardcoded CFLAGS that I'd amended:

- first, because I was compiling on a Pi2B, I changed the configure CFLAGS for the compilation to:
echo "CFLAGS = -O3 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=softfp" > /root/configparms

- then modified the armv7 CFLAGS in:
/root/slackwarearm-current/source/l/glibc/glibc.SlackBuild
to:
case $ARCH in
arm) SLKCFLAGS="-march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=softfp -pipe -g -fPIC -O3 -fno-strict-aliasing" ### -U_FORTIFY_SOURCE

- finally, got & installed & configured slackkit
wget http://ftp.slackware.pl/pub/slackwar..._softfloat.txz
installpkg slackkit-1.05-arm-1_softfloat.txz
- check slackit CFLAGS and modify accordingly
/usr/share/slackdev# egrep -e "armv5te" *
egrep: arm: Is a directory
d.SlackBuild:# arm) export SLKCFLAGS="-O2 -march=armv5te"
slackdev.config: arm) export SLKCFLAGS="-O2 -march=armv5te"
trackbuild.d: arm) export SLKCFLAGS="-O2 -march=armv5te" ;;
- all of them (the uncommented) to: "-O3 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=softfp"


- I have built the packages but it looks like the glibc-solibs-2.26-arm-1.txz is faulty and I'm out of ideas

- this is the order of the upgrades on the SlackARM 14.2 SoftFloat on a pi0:
upgradepkg glibc-2.26-arm-1.txz --> OK
Package glibc-2.23-arm-6_slack14.2 upgraded with new package ./glibc-2.26-arm-1.txz.
upgradepkg glibc-i18n-2.26-arm-1.txz --> OK
Package glibc-i18n-2.23-arm-6_slack14.2 upgraded with new package ./glibc-i18n-2.26-arm-1.txz.
upgradepkg glibc-profile-2.26-arm-1.txz --> OK
Package glibc-profile-2.23-arm-6_slack14.2 upgraded with new package ./glibc-profile-2.26-arm-1.txz.


upgradepkg glibc-solibs-2.26-arm-1.txz --> NOT OK!
+==============================================================================
| Upgrading glibc-solibs-2.23-arm-6_slack14.2 package using ./glibc-solibs-2.26-arm-1.txz
+==============================================================================

Pre-installing package glibc-solibs-2.26-arm-1...

Removing package /var/log/packages/glibc-solibs-2.23-arm-6_slack14.2-upgraded-2017-08-27,08:45:53...
--> Deleting symlink /lib/ld-linux.so.3
/sbin/removepkg: line 339: /bin/comm: No such file or directory
/sbin/removepkg: line 340: /bin/comm: No such file or directory
/sbin/removepkg: line 250: /bin/sort: No such file or directory
/sbin/removepkg: line 268: /bin/sed: No such file or directory
/sbin/removepkg: line 345: /bin/rm: No such file or directory
/sbin/removepkg: line 346: /bin/rm: No such file or directory
/sbin/removepkg: line 360: /bin/mv: No such file or directory
/sbin/removepkg: line 362: /bin/mv: No such file or directory

/sbin/upgradepkg: /sbin/installpkg: /bin/sh: bad interpreter: No such file or directory
Package glibc-solibs-2.23-arm-6_slack14.2 upgraded with new package ./glibc-solibs-2.26-arm-1.txz.

Right, "upgraded"! :)


- I compared the doinst.sh from my build with the official and the files match:
http://slackware.uk/slackwarearm/sla...2.26-arm-1.txz

- then manually decompressed some files from the package I created and checked them:

/kit/glibc-Slack-14-2-SF-armv6-softfp-FINAL/test# readelf -A libc-2.26.so
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "6ZK"
Tag_CPU_arch: v6KZ
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_FP_arch: VFPv2
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_rounding: Needed
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_user_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_enum_size: int
Tag_CPU_unaligned_access: v6
Tag_Virtualization_use: TrustZone

/kit/glibc-Slack-14-2-SF-armv6-softfp-FINAL/test# readelf -A ldconfig
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "6ZK"
Tag_CPU_arch: v6KZ
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_FP_arch: VFPv2
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_rounding: Needed
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_CPU_unaligned_access: v6
Tag_Virtualization_use: TrustZone

- ldconfig runs on both Pi2B Slack ARM - current HF and pi0 Slack 14.2 ARM SoftFloat:

/kit/glibc-Slack-14-2-SF-armv6-softfp-FINAL/test# ./ldconfig --version
ldconfig (GNU libc) 2.26
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Andreas Jaeger.


I would try this compilation directly on a pi0, but I don't think it will help. It'll only take 8 instead of 1,5 hours (actually 1h40m).
Should I use the sources from SlackARM 14.2 SoftFloat instead of SlackARM-current HardFloat for this rather old recipe?


Thanks in advance!

I got the whole compilation finished on a pi0 running SlackARM 14.2 SoftFloat - it took a little bit over 9 hours and the packages differ (md5sum) from the ones previously compiled on a Pi2B. I checked the consistency of some of the files (ldconfig ran again on both Slack platforms) and i was happy with the binaries.

However, the results are unfortunately the same:


/kit/glibc-Slack-14-2-SF-armv6-softfp-FINAL-pi0/packages# upgradepkg glibc-solibs-2.26-arm-1.txz

+==============================================================================
| Upgrading glibc-solibs-2.23-arm-6_slack14.2 package using ./glibc-solibs-2.26-arm-1.txz
+==============================================================================

Pre-installing package glibc-solibs-2.26-arm-1...

Removing package /var/log/packages/glibc-solibs-2.23-arm-6_slack14.2-upgraded-2017-08-27,20:55:53...
--> Deleting symlink /lib/ld-linux.so.3
/sbin/removepkg: line 339: /bin/comm: No such file or directory
/sbin/removepkg: line 340: /bin/comm: No such file or directory
/sbin/removepkg: line 250: /bin/sort: No such file or directory
/sbin/removepkg: line 268: /bin/sed: No such file or directory
/sbin/removepkg: line 345: /bin/rm: No such file or directory
/sbin/removepkg: line 346: /bin/rm: No such file or directory
/sbin/removepkg: line 360: /bin/mv: No such file or directory
/sbin/removepkg: line 362: /bin/mv: No such file or directory

/sbin/upgradepkg: /sbin/installpkg: /bin/sh: bad interpreter: No such file or directory
Package glibc-solibs-2.23-arm-6_slack14.2 upgraded with new package ./glibc-solibs-2.26-arm-1.txz.

Probably because of that code in glibc.SlackBuild.

Thanks, that was it!
I was looking in the build scripts only after armv7 related and missed that one.

Here's an excerpt from the build-log
patching file malloc/malloc.c
Using Plan A...
Hunk #1 succeeded at 1658 with fuzz 2.
Hunk #2 succeeded at 1671 with fuzz 2.
Hunk #3 succeeded at 1812.
done
** Found version of ld-linux: ld-linux-armhf.so.3 **
Setting sane ownerships & permissions in /root/tmp/build-glibc/glibc-2.26 ... done
mkdir: created directory 'build_dir'
checking build system type... arm-slackware-linux-gnueabi
checking host system type... arm-slackware-linux-gnueabi
checking for arm-slackware-linux-gnueabi-gcc... arm-slackware-linux-gnueabi-gcc

Obviously, this ld-linux-armhf.so.3 was then propagated in the glibc-2.26-arm-1.txz - doinst.sh :
I changed that code by copying the one from SlackARM 14.2 SoftFloat:
http://ftp.slackware.pl/pub/slackwar...ibc.SlackBuild
- there were some of these weirdos in the build log too:
../sysdeps/arm/__longjmp.S:117: IT blocks containing 32-bit Thumb instructions are deprecated in ARMv8

I'll start the compilation again on the Pi2B running SlackARM 14.2 SoftFloat and hope it will work now. These "hardcoded" HardFloat routines in other SlackBuilds will actually become handy in the second stage, when I will rebuild all the packages I need (including a mini-root) and finally rebuild glibc with hard instead of softfp.

:^] subscribed

I have managed finally to recompile glibc and I'm happy that it took some time, time during which I learned that it was all in vain. :)
There is no grey ABI-bridge area with softfp that enables you to generate HardFloat code, but the only option is to use a multilib / HardFloat enabled compiler.

Useless lessons learned so far:

- after the glibc re-compilation I checked what is gcc able to generate (only some excerpts):
- I was then trying to compile openvpn HardFloat:

- these header files are presumably generated by gcc itself (the only one package I didn't recompile - it's huge!)
- ld-linux.so.3 is a symlink to ld-2.26.so
- just by goofing around I created stubs-hard.h (copy paste from SlackARM-currentHF) and ran make again:
- the cpp compiler that comes with SlackARM 14.2 SF is apparently not configured to generate HardFloat code:
- Just by comparison on SlackARM-current HardFloat
- and cpp seems to be configured by default to generate HardFloat code
Useful lessons learned:
- the latest glibc 2.26 doesn't have --enable-multilib --disable-multilib switches in the configure script - at least they're not documented and not included in the script anymore
- I was thinking to recompile gcc too, but learned that it might take a lot of time. Finally, after gaining some courage, I started the compilation and got shortly into an error:
- the best lesson so far, is that I'll need to build my own compiler and go through the source SlackBuilds one by one.
- I might write a small script to change the hardcoded armv7 CFLAGS, but I saw some inconsistencies in the formatting and maybe a manual editing will be a safe solution.

Next steps - get a cross-compiler:
https://stackoverflow.com/questions/...ith-a-single-g
Follow Exaga's howto (thanks again!):
https://docs.slackware.com/howtos:ha...cross-compiler
Or use an already built one.

Stay tuned! :)

I updated ARM to 7.2.0 yesterday - it'll be out later today.

@abga,
Are you aware of the Linaro tool-chain I used to cross-compile uboot for ARM on my x86 machine?

It certainly doesn't run on ferry dust, but could help You wade the compile parameters a tad faster?

@SCerovec

Thanks for the hint. ATM I'm following Exaga's HowTo on gcc modifying it to get an armv6 HardFloat enabled compiler. I'm almost done, got amazed that the gcc compilation only took around 1:20 hours on a Pi2B:
https://docs.slackware.com/howtos:ha...cross-compiler

If I'm about to fail with the end result, then I might consider using some help from crosstool-ng and maybe also the Linaro compiler. I'll post my results as soon as I'm done building/compiling.

Would this apply to the 700MHz Pi's I've got?
It could use the camera then too?

It will apply for all Broadcom BCM2835 - ARMv6Z powered Raspberry Pi devices - that's my first goal. And why not, also for generic armv6 devices, depending on how you'll compile (compiler flags) the system/packages. I won't be putting available any compiled binaries/packages but only document how to obtain them. That's if I succeed :)

The performance increase by switching to HardFloat will be substantial (according to Linaro):
https://wiki.linaro.org/Linaro-arm-hardfloat
"It has been shown [1] that a typical application built with hardfloat is 5-40% faster than the softfp version. In cases of heavy floating point use, the speed increase can go even further -eg. povray was proven to be >200% faster! [2] "

If successful, I'm a little bit concerned about the way this UNSUPPORTED port will be used / assimilated by the community, as I don't wish to get in tensions with the Slackware ARM official maintainer(s) about creating too much trouble with it. It won't be supported by no one (I might be able to help here an there) and you won't be able to update the system by using the official way, but just by compiling yourself the necessary packages.

I wouldn't have started this endeavor if I hadn't had my own performance issues with SoftFloat and considering that there might be more people owning older armv6 devices, and who would like to do something more with them than just typing bash commands or doing simpler tasks.

As for your camera question, I'm not sure what you mean by "using" but only can tell you that if you can "use" it under Rasbian HardFloat, then you might be well using it also under Slack ARM - armv6 HF.
I was able to run Kodi 17 on my Pi0 under Slack ARM 14.2 SoftFloat and to watch live TV in FullHD at 25 FPS, the DVB-S2 box and the tvheadend streaming process being connected/running on the same box. I wasn't however able to watch FullHD at 50 FPS because the CPU got overwhelmed after a few minutes by the high DVB bitstream and by not using the FPU optimally. Usually a FullHD 25FPS on Satellite TV is around 8-10Mbps and the more exotic FullHD 50FPS between 13-18Mbps.
I've also read reports that openvpn is expected to give a throughput of 10-13Mbps on a Pi1 under HardFloat and my results on the Pi0 were around 5Mbps under SoftFloat...

While I can promise I'll "bread on Your neck", don't expect me to to expect anything more than the proper HOWTO.
:^]

Although an Slackbuild would be even better yet :hattip: (that I could wrap (I suppose) form the HOWTO)

the way i see it: if You pull an working Slackbuild ("just works") for any (kernel, glibc, gcc, bash?) 14.2 and onward package and we're golden?

But have in mind: the target might be LFS 1st timers, as I am ATM??

Well, after 2 evenings spent on trying to manually build gcc as a cross-compiler by following Exaga's HowTO (+ the original? post) I only can report a total failure. That gcc & the deps around it are a monster with big and sharp claws (huge and complicated configure scripts). I doubt seriously that one might be able to reproduce what Exaga has documented with updated (actual) gcc/clibc/binutils&co releases.
First I tried to build it under SlackARM 14.2 SF on a Pi2B and then moved on SlackARM current HF (on the same Pi2B board) by considering that the 14.2 packages are too old for compiling gcc 7.2.0. Unfortunately I ended up with the same apparently non-resolvable configure issue during the last step - building standard C++ Library.
I have used only the latest stable releases:
wget https://ftp.gnu.org/gnu/binutils/binutils-2.28.1.tar.xz
wget ftp://gcc.gnu.org/pub/gcc/infrastruc...-0.18.1.tar.gz
wget https://ftp.gnu.org/gnu/gcc/gcc-7.2.0/gcc-7.2.0.tar.xz
wget https://ftp.gnu.org/gnu/glibc/glibc-2.26.tar.xz
wget https://ftp.gnu.org/gnu/gmp/gmp-6.1.2.tar.xz
wget ftp://gcc.gnu.org/pub/gcc/infrastruc...0.16.1.tar.bz2
wget https://ftp.gnu.org/gnu/mpc/mpc-1.0.3.tar.gz
wget https://ftp.gnu.org/gnu/mpfr/mpfr-3.1.5.tar.xz

And the "stripped" kernel headers from Mr. drmozes (thanks! cool!):
rsync -aP rsync://ftp.arm.slackware.com/slackwarearm/slackwarearm-current/source/d/kernel-headers/ /mnt/hd/kernel-headers/

The first issue I was able to resolve was:
make[3]: *** [Makefile:487: memcpy-chk.lo] Error 1
../../../gcc-7.2.0/libssp/ssp.c: At top level:
../../../gcc-7.2.0/libssp/ssp.c:113:25: error: unknown type name ‘size_t’
fail (const char *msg1, size_t msg1len, const char *msg3)
^~~~~~
../../../gcc-7.2.0/libssp/ssp.c: In function ‘__stack_chk_fail’:
../../../gcc-7.2.0/libssp/ssp.c:185:3: warning: implicit declaration of function ‘fail’ [-Wimplicit-function-declaration]
fail (msg, strlen (msg), "stack smashing detected: terminated");

Resolution:
https://gcc.gnu.org/ml/gcc-help/2013-06/msg00047.html

The second issue is taking 99% of Google's search database (it's everywhere) and some of the solutions I've found were rather funny, magical juice, voodoo magic & co were involved. I personally tried some hula hoop in front of the compilation just to learn that it didn't help.

Last unresolvable issue during the last step - building standard C++ Library:
gcc-7.2.0/libstdc++-v3/configure
checking for shl_load... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.

Some explanations that led me to believe it's a mess inside the monster's internals and to quit my manual approach:

https://gcc.gnu.org/ml/gcc/2008-03/msg00510.html

http://sourceware-org.1504.n7.nabble...-td402076.html

https://sourceware.org/ml/crossgcc/2.../msg00031.html
"
The error is spurious. It's caused by some cruft left over from a
previous build that is screwing up a new attempt to configure your
current build.
"
https://stackoverflow.com/questions/...ling-toolchain
"
I don't know you configure command options. But if you have given --enable-language=c change it to --enable-languages=c. Or may be you are compiling bootstrap with languages c and c++. In which case this error occurs.
"

I went for crosstool-ng automatic scripts > next post

After failing to manually build my own gcc crosscompiler, I went for help at the crosstool-ng experts.
By using (gcc updated to 7.2.0) Slack ARM - current HF on a Pi2B board I followed these two recipes:
https://raspberrypi.stackexchange.co...ross-compiling
https://blog.kitware.com/cross-compi...-raspberry-pi/

The latest crosstool-ng stable Release 1.23.0 is not working with gcc 7.2.0, therefore I got their latest git build - 98b6a5a4503095ba539a415d90e3f2c5331985ed

This is what I did and got a cross-compiler that apparently is unable to produce arm & thumb1 code but only thumb2 (which is useless for armv6).

- I used an external HDD with an empty 20GB ext4 partition, however 4 GB will suffice
- as you cannot run the crosstool-ng as root, you need to run everything (config too) as a simple user and change the permissions for the working dirs accordingly (need to have wr permission in the top dir)

- go into Paths and misc options. Enable Try features marked as EXPERIMENTAL.
- choose a suitable Prefix directory.
/mnt/hd/gcc-cross/${CT_TARGET}
- local tarballs directory
/mnt/hd/tarballs/
- working directory:
/mnt/hd/work/.build
- go to the Target options menu.
Target architecture: arm
Endianness: little endian
Bitness: 32-bit
Target Architecture (arm) --->
Default instruction set mode (arm) --->
Architecture level - for Pi1/0 only:
type: armv6
Floating point: (hardware (FPU)) --->
- go to Operating system menu and change Target OS to linux.
- in C library choose:
(glibc) --->
- in C compiler choose:
(gcc) --->
gcc version (7.2.0) --->
- check c++ -[*] C++
- in Linux Kernel I choose (I'm running 4.4.50)
linux-4.4.83

- in order to give the compilation enough RAM to use - edit /boot/config.txt and set the GPU RAM at 32MB (reboot to take effect):
gpu_mem=32
- you might also want to consider protecting your SDCard from excessive wear and change the swappiness:
echo 1 > /proc/sys/vm/swappiness
- also, IMPORTANT, run the compilation with ct-ng build.4 - that's 4 jobs for the four cores, by default the ct-ng build starts more and I got my RAM and swap filled - it killed the system!
- start the compilation and consider doing something useful for around 5 hours. Some inspiration:
https://imgs.xkcd.com/comics/compiling.png

As a note, after the compilation was done I changed back the permissions:
chown -R root:root /mnt/hd/

________________________________________________

RESULTS:
- not as expected, unfortunately
- the whole cross-compiler was created without any errors, but apparently I'm not able to generate arm code and also cannot generate simple vfp FPU code, but only NEON ???

I tried to test my new cross-compiler on a simple collection of source files by doing the following:
- setting up environment

- first try - some generic armv6 HF CFLAGS - result -> useless ARM Thumb2 & NEON FPU code

export CFLAGS="-march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard"
make V=1
.....
arm-unknown-linux-gnueabihf-gcc -O2 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -c util.c

readelf -A tinymembench
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "6ZK"
Tag_CPU_arch: v6KZ
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv3
Tag_Advanced_SIMD_arch: NEONv1
Tag_ABI_VFP_args: VFP registers
Tag_CPU_unaligned_access: v6
Tag_Virtualization_use: TrustZone

- second try:
export CFLAGS="-march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -marm -mthumb"

make V=1
....
arm-unknown-linux-gnueabihf-gcc -O2 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -marm -mthumb -c util.c
In file included from util.c:26:0:
/mnt/hd/gcc-cross/arm-unknown-linux-gnueabihf/arm-unknown-linux-gnueabihf/sysroot/usr/include/stdlib.h: In function 'atoi':
/mnt/hd/gcc-cross/arm-unknown-linux-gnueabihf/arm-unknown-linux-gnueabihf/sysroot/usr/include/stdlib.h:247:1: sorry, unimplemented: Thumb-1 hard-float VFP ABI

I checked crosstool-ng configuration file again - Target section - and found that the switch for creating arm code was enabled and the thumb disabled, exactly as I was configuring it through the menu-config. Should I enable thumb there, in order to get Thumb1 code ?

Here is what the new cross-compiler is capable of:

/mnt/hd/gcc-cross/arm-unknown-linux-gnueabihf/bin/arm-unknown-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/hd/gcc-cross/arm-unknown-linux-gnueabihf/bin/arm-unknown-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/mnt/hd/gcc-cross/arm-unknown-linux-gnueabihf/libexec/gcc/arm-unknown-linux-gnueabihf/7.2.0/lto-wrapper
Target: arm-unknown-linux-gnueabihf
Configured with: /mnt/hd/work/.build/arm-unknown-linux-gnueabihf/src/gcc/configure --build=armv7l-build_unknown-linux-gnueabihf --host=armv7l-build_unknown-linux-gnueabihf --target=arm-unknown-linux-gnueabihf --prefix=/mnt/hd/gcc-cross/arm-unknown-linux-gnueabihf --with-sysroot=/mnt/hd/gcc-cross/arm-unknown-linux-gnueabihf/arm-unknown-linux-gnueabihf/sysroot --enable-languages=c,c++ --with-arch=armv6 --with-float=hard --with-pkgversion='crosstool-NG crosstool-ng-1.23.0-202-g98b6a5a4' --enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp --disable-libquadmath --disable-libquadmath-support --disable-libsanitizer --disable-libmpx --with-gmp=/mnt/hd/work/.build/arm-unknown-linux-gnueabihf/buildtools --with-mpfr=/mnt/hd/work/.build/arm-unknown-linux-gnueabihf/buildtools --with-mpc=/mnt/hd/work/.build/arm-unknown-linux-gnueabihf/buildtools --with-isl=/mnt/hd/work/.build/arm-unknown-linux-gnueabihf/buildtools --enable-lto --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-threads=posix --enable-target-optspace --disable-plugin --disable-nls --disable-multilib --with-local-prefix=/mnt/hd/gcc-cross/arm-unknown-linux-gnueabihf/arm-unknown-linux-gnueabihf/sysroot --enable-long-long
Thread model: posix
gcc version 7.2.0 (crosstool-NG crosstool-ng-1.23.0-202-g98b6a5a4)

Some excerpts only:
/mnt/hd/gcc-cross/arm-unknown-linux-gnueabihf/bin/arm-unknown-linux-gnueabihf-gcc -march=armv6zk -Q --help=target
The following options are target specific:
-mabi= aapcs-linux
-march= armv6zk
-marm [enabled]
-mcpu= [default]
-mfix-cortex-m3-ldrd [enabled]
-mflip-thumb [disabled]
-mfloat-abi= hard
-mfp16-format= none
-mfpu= auto
-mstructure-size-boundary= 32
-mthumb [disabled]
-mthumb-interwork [enabled]
-mtls-dialect= gnu
-mtp= auto
-mvectorize-with-neon-quad [enabled]
-mword-relocations [disabled]

Known ARM ABIs (for use with the -mabi= option):
aapcs aapcs-linux apcs-gnu atpcs iwmmxt

auto crypto-neon-fp-armv8 fp-armv8 fpv4-sp-d16 fpv5-d16 fpv5-sp-d16 neon neon-fp-armv8 neon-fp16 neon-vfpv3 neon-vfpv4 vfp vfp3 vfpv2 vfpv3 vfpv3-d16 vfpv3-d16-fp16
vfpv3-fp16 vfpv3xd vfpv3xd-fp16 vfpv4 vfpv4-d16


Known floating-point ABIs (for use with the -mfloat-abi= option):
hard soft softfp


It looks like the cross-compiler is properly built, according to what I was configuring the crosstool-ng for, but the results are not really working for armv6 and I'm little bit lost right now:
https://stackoverflow.com/questions/...with-gnueabihf

@SCerovec

Sorry man, as you might have noticed I'm still unable to use my "armv6 HF binaries" spitting cannon yet, but only able to get some black smoke out of the barrel ... :(
I'm also not considering Linaro, but only the gnu stuff, because I'm afraid that I might get into some compilation issues with some of the packages (including the patches). That's a thing drmozes could confirm/infirm.

I'm not sure that I might be able to write some instructions for you to be able to wrap into a script, because there are some tool-chain building related instructions and then some (basically for all packages) amending of SlackBuild scripts with some arm related CFLAGS and some tool-chain related configure switches. I'm not sure how to crosscompile only by using environmental variables and not telling the configure script what I'm expecting with (for example):
./configure --host=arm-unknown-linux-gnueabihf

Once I have my cannon ready I was considering to build (pi1/0 optimized) the packages contained in the minirootfs:
http://slackware.uk/slackwarearm/sla..._minirootfs.sh
by using the sources from Slack-current and install them in a folder and create a minirootfs package. Then create a Slack SDCard (put the kernel and the minirootfs on it) and boot it on the pi0 to see if everything is OK. After this step, just recompile all the other packages (I personally don't need the kernel/kde/kdei/x/xaps).

Usually when I look for clarifications about some ARM internals I get the word "Confusion" attached to the results. At least I'm confident now that it's not something wrong with me :)

Finally I got some good explanation about the "silly" terminology - ARM, Thumb(v1) and Tumbv2:
https://stackoverflow.com/questions/...ions-confusion

It looks like Raspberry are using thumb (maybe for compatibility) for their binaries:

readelf -A /opt/vc/bin/vcgencmd
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "ARM1176JZF-S"
Tag_CPU_arch: v6KZ
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_FP_arch: VFPv2
Tag_ABI_HardFP_use: Deprecated
Tag_ABI_VFP_args: VFP registers
Tag_CPU_unaligned_access: v6
Tag_Virtualization_use: TrustZone

I maybe should recompile my crosstools-ng generated cross-compiler with - thumb instead of arm instruction set. Another 5 hours of Pi2B grill.

(At least I managed to get rid (evaporated) of the horrible chemicals stink (reported in the Raspberry Pi forums) out of this board. It's from the U.S. (distributed by RS), there were no non-stinking Pi2B available in Europe anymore (distributed through Element14) as I started to stash some.)

By comparing the manual unfinished gcc 7.2.0 build from my first attempt with the result from crostool-ng I learned that both compilers have the:
mvectorize-with-neon-quad [enabled]

And I didn't ask specifically for it, nor could I find something in the crostool-ng configuration where I could enable/disable this optimization.
I noticed that this NEON optimization was also enabled by default in the new gcc 7.2.0 package that came for SlackARM - current HF and was wondering if it was deliberately switched on or just unintentional.
It looks like the new gcc 7.2.0 comes with it enabled by default, thus, my cross-compiler, the one generated with crostool-ng is OK.

On the Thumbv2 issue, I'm guessing that the compiler chose it deliberately because I was linking my binary with the system libs and not with the ones from the compiler's sysroot. These system libs are all Thumbv2.
ldd tinymembench
linux-vdso.so.1 (0x7eda5000)
libm.so.6 => /lib/libm.so.6 (0x76f16000)
libc.so.6 => /lib/libc.so.6 (0x76db1000)
/lib/ld-linux-armhf.so.3 (0x54b6b000)

readelf -A /lib/libm.so.6
Attribute Section: aeabi
File Attributes
Tag_THUMB_ISA_use: Thumb-2

Meanwhile I started a new cross-compiler compilation and chose to tune the cross-compiler solely for the CPU in Pi0. This will help me compile the Slack without adding the specific CFLAGS all the time:
- In Target options menu (crostools-ng interface) I filled the following in:
(armv6zk) Architecture level
(arm1176jzf-s) Tune for CPU
(vfp) Use specific FPU

Will start compiling the packages needed for the armv6 HF minirootfs once I get some more time.

hint: get the arm6 compiled *binas rootfs's and try run the
[cpde]readelf -A /lib/libm.so.6[/code]
and check if (and what) they do?
Further, afaik, Debian is 'bootstraped' from its sources each time?

just reminding? (HTH)

@SCerovec

Thanks for the hint! armv6 HF libs are nowhere available and must be compiled from the scratch. I cannot start with the ones available armv7 HF in SlackARM - current or armv6 SF in SlackARM 14.2 . Stealing some from Debian& co it's against everything I'd like to achieve.
Actually I was following AlienBOB's scripts (parts of) in order to get the first bootsrap - that's the libs I'll need in my minirootfs:
http://taper.alienbase.nl/mirrors/alienarm/bootstrap/

However, as described above, I don't have the necessary tools (compiler) to build armv6 HF VPF Thumb-1 binaries ATM . And you cannot build anything without tools, can you?

After spending a considerable amount of time with building a GNU gcc based toolchain to generate armv6 HardFloat code, I came to no results and I'm thereby quitting this SlackARM HardFloat port for armv6 struggle or "endeavor".
I might qualify now with the ones drmozes mentioned in his first post:
"However, porting Slackware is no trivial task - it's a *lot* of work. A few people have started and have not continued."
https://www.linuxquestions.org/quest...7/#post5213236

At least I've documented my struggle and the issues I came across, finally not being able to build an actual toolchain in order to help me getting started.

There might be possible solutions for getting this done, I didn't want to take those paths, and I'll enumerate 3 of them:
1. Try to build a toolchain based on the Linaro compiler and go through AlienBOB's scripts (well, part of them) on a SlackARM-current HF powered Pi2/3 and use SlackARM-current source code. However, I'm not sure the SlackARM-current source code and its patches will compile without issues under Linaro.
2. Start the compilation on an already armv6 HardFloat enabled Linux distribution (there are some), again, by following AlienBOB's scripts. This approach might be better positioned for success, but I consider it dirty. No disrespect towards other distros, not at all, but just describing the approach!
3. Try to use older GNU gcc releases (something from 4-5 years ago) on a SlackARM-current HF powered Pi2/3 and build a toolchain/crosscompiler with them, then follow AlienBOB's scripts. Here you might also have issues with the SlackARM-current source code and its patches.

In my opinion the GNU gcc is not really well/completely documented and crosstool-ng while helping a lot is also not really controllable / fine tunable. The GNU gcc latest releases look like forgetting about armv6 and focusing more on the newer ARM architectures and the issue I got into has no solution apparently:
Issue:
sorry, unimplemented: Thumb-1 hard-float VFP ABI

Some research:
https://stackoverflow.com/questions/...with-gnueabihf
https://www.raspberrypi.org/forums/v...hp?f=33&t=8758
https://forums.gentoo.org/viewtopic-...2-start-0.html
https://patchwork.ozlabs.org/patch/539155/
https://sourceware.org/ml/newlib/2013/msg00124.html

I'd also like to mention that I was trying to build a GNU gcc crosscompiler with the help of the crostool-ng (latest git) and by switching the Default instruction set mode from arm to thumb I got into build crash:
Target Architecture (arm) --->
Default instruction set mode (arm) --->
to:
Default instruction set mode (thumb) --->

By keeping my promise that I'll not quit Slackware, I just quit using the Raspberry Pi0 and will stay away from armv6 devices form now on. They're already obsolete and not marketed anymore (apart from some weirdos like the Pi0).

armv6 is dead! Long live armv6! :)

1. Kind thanks for the report
2. Condolences for the Pi0 and the demise of arm6 in the gcc (no regression in open source? how much longer?)
3. Lately I notice there will always be just an "window" of hardware supported by the free software, and there already are some trends that seem to try to squeeze it?

OTOH:
When I mentioned to "peek" to the other distros, I meant to peek to their build-scripts that "bootstrap" the GCC to cross compile, but as You seem to have found already, one could be forced to "time travel" into the "era" or the armv6 being "latest and greatest"?

-> Namely Arch and Debian proud them selves as the "bootstrap from source baby - each time" distros? Or am I dead wrong here?

One way or the other, dead lie the "lesser" pies :^[ (maybe the "Pi" pun, in the 1st place, was the intention to stress to "get them while they hot"?)

Exactly - in commerce it's budget vs demand and profit, and open source it's interest, skills and time.
I don't think armv6 ever was the latest and greatest - the distributions went from armv5 soft float -> armv7 hard float.
I don't recall ever seeing an armv6 machine anywhere until armv7 was already wide spread, and the Raspberry Pi came along sporting an older CPU.

I have not looked at bootstrapping from scratch (not that you ever boot strap from scratch - you're always using previous work) for years; but when I did back in 2003, IIRC Debian was built as was Slackware - lots of hacking, glue, string until you had a system upon which the whole package set be re-built. I don't want to think how many times I had to power down my StrongARM RiscPC and my x86 PC so that I could move the hard disk and try booting my new set of packages I'd just cross compiled. That was at the time when Emdebian was nacent, whose goal was to cross compile packages rather than build natively (as Debian does). I don't know if the work from Emdebian fed back into the main tree, but it probably did to some degree since the people involved were the heavy lifters in the Debian ARM port.

@SCerovec & @drmozes
During my work I was stumbling (internet posts) upon a lot of failed tries to get HF code for armv6 under the GNU toolchain and my impression is that this toolchain was never really able to produce such code, not without a lot of tweaking and specific configure scripts fine tuning for all its components during the toolchain build, and that explains a lot about the armv6 HF support, including Slack 14.2. It looks that this is where Linaro came across and was widely adopted in the ARM world.

@drmozes
Please do not regard the Raspberry Pi Foundation as part of the "normal" commercial realm - it's a Foundation with some specific educational goals (vision/mission), at least in theory. What they started with was selling Broadcom's already obsolete technology bundled in a cheapest possible/obtainable board. I wasn't considering buying those first boards (Pi 1) because they were pretty useless performance-wise and only opted for the Pi2B once it got released. What is happening now with these 5/10 GBP for every 10 pennies worth iteration / improvement is another story and a really interesting development. But then a "Foundation" must also grow somehow and the toys they're selling are good quality and stable, good for some SOHO projects.
As stated in another post, there are other interesting "Server Grade" ARM developments and those should be the focus for a good Linux distro.
On your "lots of hacking, glue, string until you had a system upon which the whole package set be re-built" statement - indeed, that's what scared me, not the packages compilation per se. I was considering a cross-compilation from the very beginning, and you need to build at least the system some libs from the a directory (aaa_elflibs - already compiled binaries in the source archive) and the toolchain from scratch. As stated in my last report - failure, I couldn't use anything from both SlackARM 14.2 / SlackARM - current to start with.

On armv6 (armv7 too?) system build/compilation even Google, with their 100K engineers army, are not supporting HF:
https://developer.android.com/ndk/guides/abis.html

So, in the end,
anyone giving a shot at this: Should Linaro's tool chain fail too (<- last stone unturned) - don't bother for armv6 HF?
The only unknown is which release of the tool chain is most likely to be "the winner"?

@abga and @drmozes
kind thanks for the insight of the arduous process of obtaining an "alien arch" (cross compiled) rootfs able to compile further.

The question is, even once thru with a running rootfs and an running GCC for armv6HF abi - is that uncharted territory?

Further,
is GCC the only free+open option for producing an GNU-like rootfs with an compiler?

@SCerovec
I got some spare time the other day and went through a "last try" to obtain an armv6 HF toolchain on a Slack 14.12 x86-64 powered Intel i3 spare system. I was using crosstool-ng 1.2.30 which has an already configured target called armv6-rpi-linux-gnueabi that defaults on Linaro!
https://crosstool-ng.github.io/docs/configuration/
However, the build crashed somewhere towards the end with a pretty common (found on other forums) error and I just rm -rf my work-directory/ :)
Now, I cannot compare my experience in toolchain building with the folks at crostool-ng and the fact that they choose Linaro over GNU for their armv6-HF build tells me that they might have had themselves issues with the GNU stuff before.

On your other question, as mentioned in the previous posts, AlienBob has already documented the Slack ARM build process and has some useful scripts in place, still available. Therefore it's not that much of an uncharted territory:
https://alien.slackbook.org/blog/armport/
http://taper.alienbase.nl/mirrors/alienarm/bootstrap/
But then drmozes mentioned that AlienBob got SoftFloat results with his approach:
https://www.linuxquestions.org/quest...6/#post5753195
I think, once you have a working armv6 HF toolchain, if any, you really need to pay attention how you generate the code - that's by using a sysroot, not linking the resulted binaries to your already in place system libs (which might be SoftFloat or a different arm architecture (armv7)) and pay attention to the --build= / --host= / --target= compiler flags.

sndwvs had recently obtained an aarch64 "alien" port and he might be able to provide some help with the toolchain / build process, if he wishes to.

As for me, I only have this pi0 that I got as a present and by considering the time(effort)/money efficiency ratio I'd rather spend 25EUR on an armv7 well performing board instead of wasting more time with this pretty useless pi0-armv6. Besides, pi0 boards are very hard to get - limited availability/production/faulty chips? from the previous overproduction.

Kindest thanks for the report and references (AlienBOB has amassed quite valuable stuff re Slackware bits and bolts :) )

I hope the time spent will be of good use for the ones that follow up?

:hattip:

I plan to take a bite or two when time permits, will report the outcome.

edit:
http://porteus-arm.googlecode.com/fi...-13-4-5.tar.xz
is this ^ armv6 hard float rootfs? O_o

I haven't looked much at the Linaro toolchain, but as far as I know, it includes updates and/or features for new ARM systems -- which eventually feed in to the upstream for gcc.
Personally I would not build with the Linaro toolchain for the OS because unless its usage is wide spread, you'll eventually arrive at problems that nobody else has; or if they did have them, they fixed them privately.
This is why I still use the Debian patch set for gcc. At least if there are problems, usually Debian also found them first and fixed it.

@SCerovec

I'm always documenting my efforts (even privately), work without documentation has no value for me, whatsoever. I'm happy that I was able to help you & maybe others who would like to follow up on where I left. I'd suggest to focus on obtaining an armv6 HF (able to generate) toolchain first, regardless of the platform. As drmozes suggested, stick with GNU and maybe patch it with the Debian patches from the SlackBuild. Or, go the dirty way, try Gentoo if you have a Pi1 with Ethernet. I tried it on my pi0 and I couldn't get the WiFi connected with the minimal (no kernel modules/ WiFi utilities, etc) rootfs that I was provided with from their download repo - I just dumped it. pi0 is not supported by Gentoo.

On Porteus - the link you provided is not working and on their forum I learned that they also went through my experience, but some 4 years ago. They are thanking drmozes for the support and as far as I can understand there is no armv6 HF port produced and the project looks stopped/forgotten ATM:
https://forum.porteus.org/viewtopic.php?f=112&t=1995


@drmozes
Thanks for the confirmation, I was reluctant to switch to Linaro exactly because of what you've described.

:/
bit rot at it's worst :-J