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. |
Code:
# Determine version of ld-linux.so |
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 : Code:
( cd lib ; rm -rf ld-linux-armhf.so.3 ) http://ftp.slackware.pl/pub/slackwar...ibc.SlackBuild Code:
# Determine version of ld-linux.so ../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): Code:
gcc -march=armv6zk -Q --help=target Code:
... Code:
/usr/include/gnu# ls -al Code:
/lib# readelf -A ld-2.26.so Code:
.... Code:
cpp -v Code:
/usr/include/gnu# ls -al Code:
cpp -v - 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: Code:
tar: /root/slackware64-current/source/d/gcc/gcc-7.2.0.tar.xz.sig: Not found in archive - 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! :) |
Quote:
|
@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). Code:
git clone https://github.com/crosstool-ng/crosstool-ng.git - 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) Code:
chown -R your-user:users /mnt/hd/ - 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 Code:
unset CPLUS_INCLUDE_PATH 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 Code:
export PATH=/mnt/hd/gcc-cross/arm-unknown-linux-gnueabihf/bin:$PATH 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). |
All times are GMT -5. The time now is 09:07 AM. |