LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
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-01-2014, 10:21 AM   #1
drmozes
Slackware Contributor
 
Registered: Apr 2008
Distribution: Slackware
Posts: 1,525

Rep: Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271
Slackware ARM - FAQ - soft float and hard float


Q. Why is Slackware a soft float port?

A. Slackware ARM (or 'ARMedslack' as it was previously known) was developed in 2002 when the only ARM devices on the market were soft float. It's only in recent years - 2009, 2010 that hard float machines became main stream.

For Slackware ARM to have a hard float port is an entirely new port.

alienBOB of the Slackware Core Team began a hard float port. The progress he made has been made public.

However, porting Slackware is no trivial task - it's a *lot* of work. A few people have started and have not continued.



Q. Do I need hard float?

Not necessarily. If you are using your ARM device for multi media (video, audio) then it you really do need it otherwise the performance will not be optimal, or be unviewable or have stuttering audio.

However, if you are not using your ARM device for multi media then you don't need hard float - it won't make much difference to use a soft float distribution.



Q. Can I recompile some of the packages in Slackware ARM to be hard float and leave the rest as Soft Float?

Yes!

Have a look through this article that explains about rebuilding some of the core components to use hard float:

http://mindplusplus.wordpress.com/20...-raspberry-pi/

Q. Do I need to recompile my kernel to be hard float?

No. The kernels are compiled to support the architectures selected (e.g. ARMv7 Tegra, armv6 Broadcom). When selecting the support you will either choose which features to support, or they will be baked into the CPU type anyway. So yes, if the CPU contains hardware floating point support, your kernel will be hard float.

See this discussion for more information:

http://www.linuxquestions.org/questi...at-4175495652/
 
Old 08-03-2014, 01:18 AM   #2
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 634
Blog Entries: 20

Rep: Reputation: 81
Quote:
Originally Posted by drmozes View Post
Q. Do I need to recompile my kernel to be hard float?

No. The kernels are compiled to support the architectures selected (e.g. ARMv7 Tegra, armv6 Broadcom). When selecting the support you will either choose which features to support, or they will be baked into the CPU type anyway. So yes, if the CPU contains hardware floating point support, your kernel will be hard float.

See this discussion for more information:

http://www.linuxquestions.org/questi...at-4175495652/
Adding a little more info to that:
If you're going to compile your own kernel there are still a few selections that you are left to choose and that influence how your kernel is going to deal with floating point calculations:
Code:
System Type
  [ ] Support Thumb user binaries (NEW)
  [ ] Enable ThumbEE CPU extension (NEW)

Floating point emulation
 [ ] NWFPE math emulation (NEW)
 [ ] FastFPE math emulation (EXPERIMENTAL) (NEW)
 [ ] VFP-format floating point maths (NEW)
 [ ]   Advanced SIMD (NEON) Extension support (NEW)
Depending on the system type you select the "Support Thumb user binaries" may get automatically selected wile in the "Floating Point Emulation" menu you are left to choose how your kernel should behave. The NEON extensions only pop up if you enable VFP-Format.

Now the help messages in the "Floating Point Emulation" section can cause further confusion but to my understanding NWFPE and FastFPE
make the kernel do software floating point while VFP-format is the means by which floating point calculations are passed to FPU.

As Stuart has said in other posts ... If the usernald has divorced from hardfloat the kernel will never be asked to perform hardfloat calculations.
 
Old 12-05-2016, 06:11 AM   #3
drmozes
Slackware Contributor
 
Registered: Apr 2008
Distribution: Slackware
Posts: 1,525

Original Poster
Rep: Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271
To conclude this thread:

* Slackware ARM 14.2 is "soft float" and is the last and final version of the soft float port that is maintained.
* Following on from the 14.2 release, all future releases will be hardware floating point.
* Slackware ARM "current" is hardware floating point.
 
Old 12-06-2016, 02:05 AM   #4
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 2,470
Blog Entries: 2

Rep: Reputation: 979Reputation: 979Reputation: 979Reputation: 979Reputation: 979Reputation: 979Reputation: 979Reputation: 979
Sorry drMozes:
so this effectively means:
besides kernel's FP emulation being disabled, nothing prevents the OS to boot on an FP-less host?
And other than that, only select packages make use of FP anyway?

This reminds to the MMX era and MPlayer from scratch?

So an wary owner of an sub-v7 CPU could theoretically still get an post 14.2 to run, but at the cost of rolling their own?

Not exactly Linux From Scratch, but a rather far cry from out of the box?
 
Old 12-06-2016, 02:40 AM   #5
drmozes
Slackware Contributor
 
Registered: Apr 2008
Distribution: Slackware
Posts: 1,525

Original Poster
Rep: Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271
Quote:
Originally Posted by SCerovec View Post
Sorry drMozes:
so this effectively means:
besides kernel's FP emulation being disabled, nothing prevents the OS to boot on an FP-less host?


And other than that, only select packages make use of FP anyway?

This reminds to the MMX era and MPlayer from scratch?
No, it's different. The Kernel has no link to the user space in this regard. For example, the armv7 kernel in 14.2 has no floating point emulation in it and the 14.2 Kernel was used to boot strap the hard float port.

The user land is now using the hard float ABI. It cannot run binaries from the 14.2 soft float.

Code:
# Hard float bash:
root@wizbit:~/armedslack/slackwarearm-14.2/slackware/a/Q# readelf -h /bin/bash | grep Flags
  Flags:                             0x5000400, Version5 EABI, hard-float ABI
# Soft float bash:
root@wizbit:~/armedslack/slackwarearm-14.2/slackware/a/Q# readelf -h bin/bash4.new  | grep Flags
  Flags:                             0x5000200, Version5 EABI, soft-float ABI
root@wizbit:~/armedslack/slackwarearm-14.2/slackware/a/Q#
root@wizbit:~/armedslack/slackwarearm-14.2/slackware/a/Q# ./bin/bash4.new
-bash: ./bin/bash4.new: No such file or directory

Quote:
So an wary owner of an sub-v7 CPU could theoretically still get an post 14.2 to run

As you can see, this is impossible.

Quote:
.. , but at the cost of rolling their own? Not exactly Linux From Scratch, but a rather far cry from out of the box?
Slackware is not a 'from source' distribution but you can roll your own -- after all, that's what I do, right? :-)

Not that I have any prescience about the demise of the software floating support in ARM, but I've written about why I dropped the soft float port: summary - ARM community is small (for all distributions) and incredibly fragmented. Unless the masses are still using soft float OS or hardware that does not have FPU, the soft float port dies out of lack of use and maintenance. It happened with the 'old ABI' (Slackware/armedslack <=12.2), happened with the Mozilla suite. You either keep up with the pack, try and support yourself or die off. It's just economics and numbers of contributors.

Last edited by drmozes; 12-06-2016 at 02:48 AM.
 
1 members found this post helpful.
Old 01-13-2017, 09:43 AM   #6
onebuck
Moderator
 
Registered: Jan 2005
Location: Central Florida 20 minutes from Disney World
Distribution: SlackwareŽ
Posts: 13,922
Blog Entries: 44

Rep: Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158
Member response

Hi,

drmozes, will you be doing a 64Bit for SlackwareARM? I posted; First 64-Bit and Enterprise OS Comes to Raspberry Pi 3

Just wondering if you know of anyone working on a SlackwareARM64?

Thanks for all the Slackware ARM work.
 
Old 01-13-2017, 09:46 AM   #7
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 634
Blog Entries: 20

Rep: Reputation: 81
Have a look at this thread.
 
Old 01-13-2017, 01:31 PM   #8
onebuck
Moderator
 
Registered: Jan 2005
Location: Central Florida 20 minutes from Disney World
Distribution: SlackwareŽ
Posts: 13,922
Blog Entries: 44

Rep: Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158Reputation: 3158
Member response

Hi,

Quote:
Originally Posted by louigi600 View Post
Have a look at this thread.
Thanks! I had already looked at that link and was wondering if a SlackwareARM64 would be created for the full Slackware64 distribution tree. It seems it would be a major challenge and wonder if anyone has been working on a ARM distro for Slackware64.
 
Old 01-13-2017, 01:42 PM   #9
drmozes
Slackware Contributor
 
Registered: Apr 2008
Distribution: Slackware
Posts: 1,525

Original Poster
Rep: Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271
Quote:
Originally Posted by onebuck View Post
Hi,



Thanks! I had already looked at that link and was wondering if a SlackwareARM64 would be created for the full Slackware64 distribution tree. It seems it would be a major challenge and wonder if anyone has been working on a ARM distro for Slackware64.
I started changing the build scripts to accommodate it but it'd be a huge piece of work, so probably not.
I've spent several hours just hacking around getting two Orange Pi boards supported, and trawling through mailing lists looking for hints as to whether anyone else'd come across the same issues.

I'd probably look at 64bit properly once and only once hard float is coming towards end of life upstream, as soft float did.

Last edited by drmozes; 01-13-2017 at 01:46 PM.
 
Old 01-13-2017, 06:39 PM   #10
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 2,470
Blog Entries: 2

Rep: Reputation: 979Reputation: 979Reputation: 979Reputation: 979Reputation: 979Reputation: 979Reputation: 979Reputation: 979
^_^ looking forward to either (and to help if I can)

Kudos to longtime (longer than me) fellow slackers
 
Old 01-14-2017, 07:56 AM   #11
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware AArch64
Posts: 1,043

Rep: Reputation: 665Reputation: 665Reputation: 665Reputation: 665Reputation: 665Reputation: 665
Quote:
Originally Posted by drmozes View Post
I started changing the build scripts to accommodate it but it'd be a huge piece of work, so probably not.

I'd probably look at 64bit properly once and only once hard float is coming towards end of life upstream, as soft float did.
Huge as the task may be, given the knowledge and experience of Slackware users within these forums, it's not beyond the bounds of possibility or out of the question. Where there's a will, there's always a way. Finding "the way" might be hard at first, but then nothing worthwhile is ever easy or convenient.

Quote:
Originally Posted by onebuck View Post
I had already looked at that link and was wondering if a SlackwareARM64 would be created for the full Slackware64 distribution tree. It seems it would be a major challenge and wonder if anyone has been working on a ARM distro for Slackware64.
The notion of Slackware ARM64 at this moment in time might appear to be over-imaginative and unrealistic, but it is neither inconceivable nor impossible to achieve. The challenges that exist are rebuilding the entire Slackware ARM tree for AArch64 architecture and then maintaining it. I cannot begin to ascertain the amount of effort and time involved in undertaking such a task, as a solo effort. However, the vision of Slackware ARM 64-bit port is never far from my thoughts on a daily basis. I have a deeply rooted, unbridled and unrestrained, passion for Slackware (especially the ARM port) and it's this which gives me a purpose and reason, and the motivation, to achieve.

The SARPi Project was initially conceived from much the same vision of 'what could be'. A friend and I first discussed Slackware ARM on a Raspberry Pi in 2011 - quite a few months before the device became publicly available. We started out with not much more than a dream and a head full of ideas, and took on the seemingly monumental task of turning those fanciful speculations into a reality. What you see now from the SARPi Project is the result of a lot of invested time, hard work, and the help/assistance of many, many people over the past +4 years.

When you have a clear vision of your goal(s), as we did, it does not matter how long or difficult the road might be in order to accomplish them. If you want to achieve and be successful then you need to have faith in your hopes, aspirations, and especially your dreams.

I haven't yet given up on my dreams.

Last edited by Exaga; 01-14-2017 at 07:58 AM.
 
4 members found this post helpful.
Old 08-19-2017, 10:59 PM   #12
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
@drmozes & all

It's an old topic but my actual problems are very on-topic, no need to start a new thread I guess.

I'm trying to get a lately unused (just attracting dust on my desk) Raspberry Pi0 1.3 as a multimedia device running Kodi and got entangled into the arm philosophy (sorry, can't call it science, not yet). In short, I'm about to recompile the Slackware ARM 14.2 (or maybe better the ARM current) system libs (some of them that Kodi depends on) with the compiler flags: -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard, in order to get them optimized for the Pi0.
I'm still not sure if my Raspberry official kernel 4.4.50+ natively supports hard float calls, if my newly compiled libs will still be able to work for some other programs that depend on them and if the hard float emulation -mfloat-abi=softfp is not worse than just the actual -mfloat-abi=soft from performance perspective.
Furthermore, the compiler that comes with Slackware arm 14.2 doesn't seem to have the necessary libraries to compile with the -mfloat-abi=hard flag. Just by testing, trying to compile openvpn with hard-float support I got into this compiler error:

libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O2 -std=c99 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -MT compat-lz4.lo -MD -MP -MF .deps/compat-lz4.Tpo -c compat-lz4.c -fPIC -DPIC -o .libs/compat-lz4.o
In file included from /usr/include/features.h:392:0,
from /usr/include/stdlib.h:24,
from compat-lz4.c:112:
/usr/include/gnu/stubs.h:10:29: fatal error: gnu/stubs-hard.h: No such file or directory
compilation terminated.

Adding to my confusion were these old answers:

Your statement:
_______
Q. Can I recompile some of the packages in Slackware ARM to be hard float and leave the rest as Soft Float?

Yes!

Have a look through this article that explains about rebuilding some of the core components to use hard float:

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

- the Debian arm wiki (the most complete info I could get ATM) explains that softfp, while implemented for compatibility, is worse than soft from performance perspective:
https://wiki.debian.org/ArmHardFloatPort/VfpComparison

And:

Your statement:
________
No, it's different. The Kernel has no link to the user space in this regard. For example, the armv7 kernel in 14.2 has no floating point emulation in it and the 14.2 Kernel was used to boot strap the hard float port.
_______
- according to this, the kernel should also have support for vfp calls:
https://raspberrypi.stackexchange.co...es-on-a-soft-f

Now, I got Kodi and all the dependencies compiled and packed (slack packages) on a Pi2B with:
-march=armv6zk -mtune=arm1176jzf-s -mfloat-abi=soft
moved them to my Pi0 running the official soft float Slack arm 14.2 & Raspberry's official kernel 4.4.50+ and got everything running almost perfect. Almost, because of some performance issues, frame drops, high IRQ count (8000 on pi0 Soft Float compared to 1500 on Pi2 Hard Float), and stalls with 100% CPU usage, issues that the Pi2 (having the same GPU, I reckon, armv7 is a little faster than armv6) handles without any issues under Hard Float binaries/libs/kernel on one core.

Interestingly, when I booted the official Raspbian Image on my Pi0, in order to nick the kernel headers, I got the 4.4.50-v7+ loaded and I'm not sure why under Slackware ARM 14.2 I get the 4.4.50+
I know that there are some routines in the booting sequence of the Pi (the code that gets loaded by the GPU) that check the system architecture and are loading an appropriate kernel, but are these routines also mounting the root partition and checking how init was compiled ? weird...
https://raspberrypi.stackexchange.co...kernel-to-load

I would be more than thankful if you could be so kind and with your actual knowledge&experience shed some light over the dark maze I'm lost in and maybe also help me consider arm a science and not a philosophy

Last edited by abga; 08-20-2017 at 11:53 AM.
 
Old 08-20-2017, 01:18 PM   #13
drmozes
Slackware Contributor
 
Registered: Apr 2008
Distribution: Slackware
Posts: 1,525

Original Poster
Rep: Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271
Quote:
Originally Posted by abga View Post
Q. Can I recompile some of the packages in Slackware ARM to be hard float and leave the rest as Soft Float?

Yes!
This means that you can compile to use the hardware floating point, but remain using the soft float user land ABI.
This is not what's colloquially called "hard float" - where the entire OS is built using the hardware floating point ABI, which is incompatible with the software floating point ABI.

This URL is now dead, but it was using softfp.

Quote:
- the Debian arm wiki (the most complete info I could get ATM) explains that softfp, while implemented for compatibility, is worse than soft from performance perspective:
I would not do that, then :-)


Quote:
No, it's different. The Kernel has no link to the user space in this regard. For example, the armv7 kernel in 14.2 has no floating point emulation in it and the 14.2 Kernel was used to boot strap the hard float port.
_______
- according to this, the kernel should also have support for vfp calls:
https://raspberrypi.stackexchange.co...es-on-a-soft-f
The article you linked to does a good job of explaining what I was referring to in the quote above.

I knew what the h/w floating point emulation did in the original ARMedslack back in 2005, where a Kernel module emulated a hardware floating point unit, and trapped the kernel exceptions, but I don't know what CONFIG_VFP does without reading more about it. However, I am talking about the difference between the distinction between the user land ABI and the Kernel -- where as, as far as I know (without further reading), there's no link.
The "hardware floating point" (currently only in Slackware ARM current) refers to the OS/user land being compiled to use the hardware floating point ABI, and nothing more. The single Kernel supplied supports the SoC's that use armv7 and the FPU instructions. Even though the Kernel config for the armv7 Kernel within 14.2 supports it:
Code:
root@wizbit:~/armedslack/slackwarearm-14.2/source/k/configs# egrep '^CON.*NEON|^CON.*VFP' config-armv7
CONFIG_VFP=y
CONFIG_VFPv3=y
CONFIG_NEON=y
CONFIG_KERNEL_MODE_NEON=y
CONFIG_CRYPTO_SHA1_ARM_NEON=m
My guess would be that unless you compiled something using softfp, there'd be no use of the hardware floating point unit on am armv7 machine running 14.2.

For a multimedia machine on one of these Raspberry Pi's that has a CPU <armv7, I'd use Raspbian since the OS is built to use the hardware floating point unit.

Last edited by drmozes; 08-20-2017 at 01:20 PM.
 
Old 08-20-2017, 03:31 PM   #14
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
@drmozes
Many thanks for your quick reply!

I just got the latest openvpn compiled under Slackware ARM current on one of my Pi2B with: -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard
Created a slack package, moved the package over to the Pi0 running Slackware 14.2 SoftFloat, installed it and launched openvpn just to see it not being recognized by the system:

readelf -A /usr/local/sbin/openvpn
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "7-A"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv3-D16
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_VFP_args: VFP registers
Tag_CPU_unaligned_access: v6
Tag_Virtualization_use: TrustZone

While the compiler from the official Slackware ARM 14.2 soft float is broken, it cannot create HardFloat code, I was using the compiler from Slack ARM current under a Pi2B box and as I see now I got the arm v7 code generated instead of armv6 when using -mfpu=vfp -mfloat-abi=hard
The VFP code Tag_FP_arch: VFPv3-D16 looks good though for the arm v6 architecture...


The link is not dead but it was me pasting a truncated one (corrected now in my post) and indeed it was using softfp emulation:
https://mindplusplus.wordpress.com/2...-raspberry-pi/

On your Raspbian recommendation for < armv7, thank you, but no thank you. I already got banned from the Raspbian Forum by not accepting their Debian offer (forced down my throat) and loving Slack so much Not to mention I need to get used with systemd!
I was looking at Gentoo for my Pi0, as they have HardFloat support for armv6, but learned that I have to compile the whole stuff and then thought - why not doing it with Slackware then?
I'm not sure what to make of this Pi0 (apart from throwing it away) and it's not only multimedia I'm looking after, but also a small VPN box as an alternative. On armv7 HardFloat with AES256 I get a throughput around 30Mbps on one core and with armv6 SoftFloat it's 5Mbit, useless.
 
Old 08-20-2017, 04:18 PM   #15
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
It looks like the compiler from Slackware ARM current (with the latest updates) is also unable to generate armv6 code when -mfpu=vfp -mfloat-abi=hard flags are used. Native armv7 code is created instead.
In my first attempt to get openvpn compiled for armv6 I manually modified the CFLAGS section of the Makefiles. I'm doing this usually with configure scripts that don't have an option for compiler flags and also don't like environmental compiler variables.

Now, in my second attempt I just used CFLAGS env variables and although the compilation itself used them, like it did before with the modified Makefiles, the generated bin is still native armv7:


export CFLAGS="$CFLAGS -g -O2 -std=c99 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard"

echo $CFLAGS
-g -O2 -std=c99 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard

./configure --disable-server --disable-plugins --disable-management --disable-multihome --disable-port-share --enable-small --enable-iproute2 --disable-plugin-auth-pam --disable-plugin-down-root --disable-pf

- the Makefiles contain:
CFLAGS = -g -O2 -std=c99 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard

make -j 4 V=1

....
/bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O2 -std=c99 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -MT compat-dirname.lo -MD -MP -MF .deps/compat-dirname.Tpo -c -o compat-dirname.lo compat-dirname.c
/bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O2 -std=c99 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -MT compat-basename.lo -MD -MP -MF .deps/compat-basename.Tpo -c -o compat-basename.lo compat-basename.c
/bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O2 -std=c99 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -MT compat-gettimeofday.lo -MD -MP -MF .deps/compat-gettimeofday.Tpo -c -o compat-gettimeofday.lo compat-gettimeofday.c
/bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O2 -std=c99 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -MT compat-daemon.lo -MD -MP -MF .deps/compat-daemon.Tpo -c -o compat-daemon.lo compat-daemon.c
....

make install DESTDIR=/tmp/build

readelf -A /tmp/build/usr/local/sbin/openvpn
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "7-A"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv3-D16
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_VFP_args: VFP registers
Tag_CPU_unaligned_access: v6
Tag_Virtualization_use: TrustZone


Are there any other compiler options I need to tune or what compiler should I use to be able to both generate armv6 & armv7 HardFloat code ?

Thanks in advance!
 
  


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
SlackwareARM on RaspberryPI and soft/hard float andrixnet Slackware - ARM 20 10-08-2014 08:02 PM
Hard float/soft float interndan Slackware - ARM 5 08-01-2014 10:23 AM
[SOLVED] gcc 4.6.3 'invalid operands to binary % ( have 'float' and 'float' ) error curious95 Programming 6 02-22-2013 08:51 AM
count digits of a float || convert float to string nadroj Programming 6 07-11-2005 04:52 PM

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

All times are GMT -5. The time now is 09:43 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
Open Source Consulting | Domain Registration