[haiku-commits] Re: haiku: hrev47150 - in build: scripts jam/board/beagle
- From: pulkomandy <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Tue, 22 Apr 2014 12:18:22 +0200
On Tue, Apr 22, 2014 at 11:15:04AM +0200, Ithamar R. Adema wrote:
> Is all this hardcoding really necessary? Isn't the core problem here that
> the haikuporter based builds aren't using the
> "HAIKU_*FLAGS_$(HAIKU_PACKAGING_ARCH)"
> flags, and therefore there are mismatches between VFP implementations and
> such?
Yes, this is the problem, however I'm not sure how wecould reliably set
the CFLAGS and CXXFLAGS for all ports, as they all use different build
systems and thus have different ways of setting the flags.
>
> The fact that the older ARM architectures don't have atomic operations in
> the instruction set is already handled on Haiku by having them as syscalls,
> and these could be used to implement the missing atomic operations. I can
> imagine you're not motivated to fix those, but breaking all non-ARMv7
> targets looks like a bit brute force to me.
>
> Please correct me if I'm wrong, and I'm not saying you should revert, just
> trying to figure out why all of this is necessary.
The problem is a mix of VFP vs non-VFP and pre-ARMv7 archs needing more
syscalls than we currently implement. What I'm going to do next is:
- Keep the current "arm" architecture targetting ARMv7-A devices with
hardware floating point.
- Introduce an "arm-softfp" (or is there a better name for that?) architecture,
that will target hardware without floating point units, and could be set to
ARMv5 or ARMv6 as a default.
I think it is a good idea to keep these separate, as this way all
packages for the "arm" arch can use the modern instructions, hardware
floats, and other nice things in ARMv7. Later on, we could do hybrid
images to allow running softfp apps on an ARMv7 install. We will need
such an hybrid system if we want to build a multilib compiler for it,
too, because the compiler needs to link against the host libraries.
Finally, the addition of a default arch to the compiler doesn't remove
the ability to generate code for other archs, if you pass the -mcpu,
-mfloat-abi and -march flags as usual. Only the default value is
changed. So if we can figure out a way to get those flags passed
everywhere they need to be, it will fix things for non-ARMv7 targets.
However, this won't work well because the multilib build of the compiler
was disabled, but we can re-enable that once the flags are properly
passed everywhere.
Other related posts:
