LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 08-27-2017, 03:16 AM   #1
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware x86 & ARM
Posts: 135

Rep: Reputation: 42
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!

Last edited by abga; 08-27-2017 at 03:18 AM.
 
Old 08-27-2017, 02:06 PM   #2
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware x86 & ARM
Posts: 135

Original Poster
Rep: Reputation: 42
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.
 
Old 08-27-2017, 03:16 PM   #3
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 607

Rep: Reputation: 430Reputation: 430Reputation: 430Reputation: 430Reputation: 430
Code:
  # Determine version of ld-linux.so
  export ARMLDLINUXVER="$( grep -A1 "hard-float ABI" sysdeps/unix/sysv/linux/arm/shlib-versions | egrep "^ld=" | awk -F= '{print $2}' )"
  if [ -z "ARMLDLINUXVER" ]; then
     echo "Unable to determine version of ld-linux.so required for the package doinst.sh"
     exit 1
   else
     echo "** Found version of ld-linux: $ARMLDLINUXVER **"
  fi
Probably because of that code in glibc.SlackBuild.
 
Old 08-27-2017, 05:32 PM   #4
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware x86 & ARM
Posts: 135

Original Poster
Rep: Reputation: 42
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 )
( cd lib ; ln -sf ld-2.26.so ld-linux-armhf.so.3 )
I changed that code by copying the one from SlackARM 14.2 SoftFloat:
http://ftp.slackware.pl/pub/slackwar...ibc.SlackBuild
Code:
  # Determine version of ld-linux.so
  export ARMLDLINUXVER="$( grep -A1 "soft-float ABI" sysdeps/unix/sysv/linux/arm/shlib-versions | egrep "^ld=" | awk -F= '{print $2}' )"
  #export ARMLDLINUXVER="$( grep -A1 "hard-float ABI" sysdeps/unix/sysv/linux/arm/shlib-versions | egrep "^ld=" | awk -F= '{print $2}' )"
  if [ -z "ARMLDLINUXVER" ]; then
     echo "Unable to determine version of ld-linux.so required for the package doinst.sh"
     exit 1
   else
     echo "** Found version of ld-linux: $ARMLDLINUXVER **"
  fi
- 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.
 
Old 08-28-2017, 08:55 AM   #5
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 1,168
Blog Entries: 2

Rep: Reputation: 166Reputation: 166
:^] subscribed
 
Old 08-28-2017, 08:35 PM   #6
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware x86 & ARM
Posts: 135

Original Poster
Rep: Reputation: 42
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
The following options are target specific:
  -mabi=                                aapcs-linux
  -march=                               armv6zk
  -mcpu=                                [default]
  -mfix-cortex-m3-ldrd                  [enabled]
  -mfloat-abi=                          soft
  -mfp16-format=                        none
  -mfpu=                                vfp
  -mglibc                               [enabled]
  -mhard-float


 Known ARM architectures (for use with the -march= option):
    armv2 armv2a armv3 armv3m armv4 armv4t armv5 armv5e armv5t armv5te armv6 armv6-m armv6j armv6k armv6s-m armv6t2 armv6z armv6zk armv7 armv7-a armv7-m armv7-r armv7e-m armv7ve
    armv8-a armv8-a+crc iwmmxt iwmmxt2 native

  Known floating-point ABIs (for use with the -mfloat-abi= option):
    hard soft softfp
- I was then trying to compile openvpn HardFloat:

Code:
...
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I../../src/compat        -g -O3 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -MT crypto.o -MD -MP -MF .deps/crypto.Tpo -c -o crypto.o crypto.c
In file included from /usr/include/features.h:447:0,
                 from /usr/include/sys/time.h:21,
                 from ../../src/compat/compat.h:37,
                 from syshead.h:28,
                 from base64.c:40:
/usr/include/gnu/stubs.h:10:29: fatal error: gnu/stubs-hard.h: No such file or directory
- these header files are presumably generated by gcc itself (the only one package I didn't recompile - it's huge!)
Code:
/usr/include/gnu# ls -al
total 56
drwxr-xr-x   2 root root  4096 Aug 28 22:59 .
drwxr-xr-x 378 root root 28672 Aug 28 22:58 ..
-rw-r--r--   1 root root  1708 Aug 28 22:58 lib-names-soft.h
-rw-r--r--   1 root root   374 Aug 28 22:52 lib-names.h
-rw-r--r--   1 root root  1263 Aug 28 22:52 libc-version.h
-rw-r--r--   1 root root   742 Aug 28 22:59 stubs-soft.h
-rw-r--r--   1 root root   295 Aug 28 22:52 stubs.h

head lib-names-soft.h
/* This file is automatically generated.  */
#ifndef __GNU_LIB_NAMES_H
# error "Never use <gnu/lib-names-soft.h> directly; include <gnu/lib-names.h> instead."
#endif

#define LD_LINUX_SO                     "ld-linux.so.3"
#define LD_SO                           "ld-linux.so.3"
#define LIBANL_SO                       "libanl.so.1"
#define LIBBROKENLOCALE_SO              "libBrokenLocale.so.1"
#define LIBCIDN_SO                      "libcidn.so.1"
- ld-linux.so.3 is a symlink to ld-2.26.so
Code:
/lib# readelf -A ld-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_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_ABI_optimization_goals: Aggressive Speed
  Tag_CPU_unaligned_access: v6
  Tag_Virtualization_use: TrustZone
/lib# ls -al ld-2.26.so
-rwxr-xr-x 1 root root 167124 Aug 28 22:46 ld-2.26.so
- just by goofing around I created stubs-hard.h (copy paste from SlackARM-currentHF) and ran make again:
Code:
....
proxy.o ps.o push.o reliable.o route.o schedule.o session_id.o shaper.o sig.o socket.o socks.o ssl.o ssl_openssl.o ssl_polarssl.o ssl_verify.o ssl_verify_openssl.o ssl_verify_polarssl.o status.o tun.o win32.o cryptoapi.o  ../../src/compat/.libs/libcompat.a -lnsl -lresolv /usr/lib/liblzo2.so -lssl -lcrypto
/usr/lib/gcc/arm-slackware-linux-gnueabi/5.3.1/../../../../arm-slackware-linux-gnueabi/bin/ld: error: base64.o uses VFP register arguments, openvpn does not
/usr/lib/gcc/arm-slackware-linux-gnueabi/5.3.1/../../../../arm-slackware-linux-gnueabi/bin/ld: failed to merge target specific data of file base64.o
/usr/lib/gcc/arm-slackware-linux-gnueabi/5.3.1/../../../../arm-slackware-linux-gnueabi/bin/ld: error: buffer.o uses VFP register arguments, openvpn does not
/usr/lib/gcc/arm-slackware-linux-gnueabi/5.3.1/../../../../arm-slackware-linux-gnueabi/bin/ld: failed to merge target specific data of file buffer.o
- the cpp compiler that comes with SlackARM 14.2 SF is apparently not configured to generate HardFloat code:
Code:
cpp -v
Reading specs from /usr/lib/gcc/arm-slackware-linux-gnueabi/5.3.1/specs
COLLECT_GCC=cpp
Target: arm-slackware-linux-gnueabi
Configured with: ../gcc-5.3.1/configure --prefix=/usr --mandir=/usr/man --infodir=/usr/info --libdir=/usr/lib --enable-bootstrap --enable-checking=release --with-system-zlib --disable-libunwind-exceptions --with-python-dir=/lib/python2.7/site-packages --enable-libstdcxx-dual-abi --with-default-libstdcxx-abi=gcc4-compatible --enable-shared --enable-languages=ada,c,c++,fortran,go,java,objc,lto --enable-objc-gc --enable-threads=posix --enable-__cxa_atexit --enable-libssp --enable-lto --with-gnu-ld --verbose --enable-java-home --with-java-home=/usr/lib/jvm/jre --with-jvm-root-dir=/usr/lib/jvm --with-jvm-jar-dir=/usr/lib/jvm/jvm-exports --with-arch-directory= --with-antlr-jar=/root/slackware64-current/source/d/gcc/antlr-runtime-3.4.jar --enable-java-awt=gtk --disable-gtktest --disable-install-libiberty --host=arm-slackware-linux-gnueabi --build=arm-slackware-linux-gnueabi --target=arm-slackware-linux-gnueabi
Thread model: posix
gcc version 5.3.1 20160409 (GCC)
COLLECT_GCC_OPTIONS='-E' '-v' '-mtls-dialect=gnu'
 /usr/libexec/gcc/arm-slackware-linux-gnueabi/5.3.1/cc1 -E -quiet -v - -mtls-dialect=gnu
ignoring nonexistent directory "/usr/lib/gcc/arm-slackware-linux-gnueabi/5.3.1/../../../../arm-slackware-linux-gnueabi/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/arm-slackware-linux-gnueabi/5.3.1/include
 /usr/local/include
 /usr/lib/gcc/arm-slackware-linux-gnueabi/5.3.1/include-fixed
 /usr/include
End of search list.
- Just by comparison on SlackARM-current HardFloat
Code:
/usr/include/gnu# ls -al
total 60
drwxr-xr-x   2 root root  4096 Aug  6 11:57 .
drwxr-xr-x 392 root root 32768 Aug  6 11:57 ..
-rw-r--r--   1 root root  1720 Aug  6 11:57 lib-names-hard.h
-rw-r--r--   1 root root   374 Aug  6 11:52 lib-names.h
-rw-r--r--   1 root root  1263 Aug  6 11:52 libc-version.h
-rw-r--r--   1 root root   742 Aug  6 11:57 stubs-hard.h
-rw-r--r--   1 root root   295 Aug  6 11:52 stubs.h

head lib-names-hard.h
/* This file is automatically generated.  */
#ifndef __GNU_LIB_NAMES_H
# error "Never use <gnu/lib-names-hard.h> directly; include <gnu/lib-names.h> instead."
#endif

#define LD_LINUX_ARMHF_SO               "ld-linux-armhf.so.3"
#define LD_SO                           "ld-linux-armhf.so.3"
#define LIBANL_SO                       "libanl.so.1"
#define LIBBROKENLOCALE_SO              "libBrokenLocale.so.1"
#define LIBCIDN_SO                      "libcidn.so.1"
- and cpp seems to be configured by default to generate HardFloat code
Code:
cpp -v
Reading specs from /usr/lib/gcc/arm-slackware-linux-gnueabi/7.1.0/specs
COLLECT_GCC=cpp
Target: arm-slackware-linux-gnueabi
Configured with: ../gcc-7.1.0/configure --with-march=armv7-a --with-float=hard --disable-werror --prefix=/usr --mandir=/usr/man --infodir=/usr/info --libdir=/usr/lib --enable-bootstrap --enable-checking=release --with-system-zlib --disable-libunwind-exceptions --enable-libstdcxx-dual-abi --with-default-libstdcxx-abi=gcc4-compatible --enable-shared --enable-languages=c,c++,ada,fortran,go,lto,objc --enable-objc-gc --enable-threads=posix --enable-__cxa_atexit --enable-libssp --enable-lto --with-gnu-ld --verbose --with-arch-directory= --disable-gtktest --disable-install-libiberty --host=arm-slackware-linux-gnueabi --build=arm-slackware-linux-gnueabi --target=arm-slackware-linux-gnueabi
Thread model: posix
gcc version 7.1.0 (GCC)
COLLECT_GCC_OPTIONS='-E' '-v' '-mfloat-abi=hard' '-mtls-dialect=gnu'
 /usr/libexec/gcc/arm-slackware-linux-gnueabi/7.1.0/cc1 -E -quiet -v - -mfloat-abi=hard -mtls-dialect=gnu
ignoring nonexistent directory "/usr/lib/gcc/arm-slackware-linux-gnueabi/7.1.0/../../../../arm-slackware-linux-gnueabi/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/arm-slackware-linux-gnueabi/7.1.0/include
 /usr/local/include
 /usr/lib/gcc/arm-slackware-linux-gnueabi/7.1.0/include-fixed
 /usr/include
End of search list.
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:
Code:
tar: /root/slackware64-current/source/d/gcc/gcc-7.2.0.tar.xz.sig: Not found in archive
tar: Exiting with failure status due to previous errors
  gcc-7.1.0-arm-2.txz.build.log:  2.388:1,  3.351 bits/byte, 58.12% saved, 1817 in, 761 out.
^C
[1]+  Done                    nohup arm/build 2>&1 | tee /root/build.log
- 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!

Last edited by abga; 08-28-2017 at 11:53 PM. Reason: typo
 
Old 08-29-2017, 02:55 AM   #7
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 607

Rep: Reputation: 430Reputation: 430Reputation: 430Reputation: 430Reputation: 430
Quote:
Originally Posted by abga View Post
tar: /root/slackware64-current/source/d/gcc/gcc-7.2.0.tar.xz.sig: Not found in archive
tar: Exiting with failure status due to previous errors
gcc-7.1.0-arm-2.txz.build.log: 2.388:1, 3.351 bits/byte, 58.12% saved, 1817 in, 761 out.
I updated ARM to 7.2.0 yesterday - it'll be out later today.

Last edited by drmozes; 08-29-2017 at 03:18 AM.
 
Old 08-30-2017, 10:48 AM   #8
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 1,168
Blog Entries: 2

Rep: Reputation: 166Reputation: 166
@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?
 
Old 08-30-2017, 12:43 PM   #9
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware x86 & ARM
Posts: 135

Original Poster
Rep: Reputation: 42
@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.

Last edited by abga; 08-30-2017 at 03:56 PM.
 
Old 08-30-2017, 05:34 PM   #10
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 1,168
Blog Entries: 2

Rep: Reputation: 166Reputation: 166
Would this apply to the 700MHz Pi's I've got?
It could use the camera then too?
 
Old 08-30-2017, 07:08 PM   #11
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware x86 & ARM
Posts: 135

Original Poster
Rep: Reputation: 42
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...

Last edited by abga; 08-30-2017 at 07:36 PM. Reason: typos - plenty of them :)
 
Old 09-02-2017, 04:17 PM   #12
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 1,168
Blog Entries: 2

Rep: Reputation: 166Reputation: 166
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 (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??
 
Old 09-02-2017, 06:27 PM   #13
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware x86 & ARM
Posts: 135

Original Poster
Rep: Reputation: 42
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
 
Old 09-02-2017, 07:16 PM   #14
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware x86 & ARM
Posts: 135

Original Poster
Rep: Reputation: 42
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
cd crosstool-ng
./bootstrap
./configure
make -j 4 V=1
make install
ldconfig
- 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)

Code:
chown -R your-user:users /mnt/hd/
su your-user
cd /mnt/hd/
# the .config file will be created here!
ct-ng menuconfig
- 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

Code:
unset CPLUS_INCLUDE_PATH
nohup ct-ng build.4 2>&1 | tee /mnt/hd/ct-ng.log &
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

Code:
export PATH=/mnt/hd/gcc-cross/arm-unknown-linux-gnueabihf/bin:$PATH
export CROSS_COMPILE=arm-unknown-linux-gnueabihf-
export CC=arm-unknown-linux-gnueabihf-gcc
- 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

Last edited by abga; 09-03-2017 at 03:07 AM. Reason: added compilation optimization - RAM - swappiness - shorter format
 
Old 09-02-2017, 07:41 PM   #15
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware x86 & ARM
Posts: 135

Original Poster
Rep: Reputation: 42
@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).
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Compiler behavior on both SlackARM 14.2 SF and SlackARM current after latest updates Aug 2017 abga Slackware - ARM 12 08-29-2017 02:22 PM
[SOLVED] Banana PI USB ports not working on -current (ex14.2) hardfloat SCerovec Slackware - ARM 8 10-15-2016 05:40 AM
LXer: Raspberry Pi 2: Raspbian (ARMv6) v Linaro (ARMv7) LXer Syndicated Linux News 0 03-15-2015 05:20 PM
[SOLVED] how to write the compiler command or in Makefile to ARMv6 georgewhr Linux - Software 6 10-28-2013 09:37 AM
struggling to port forward apache 1.3 dynamicsamurai Linux - Networking 1 06-15-2005 02:40 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 02:46 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration