I would like to try to move the optflags definition into the macro file
to make it cleaner and easier to maintain, so to make that easier, I
wanted to start by removing unsupported arches, so there is less code
to move.
Match other architectures by adding missing flags:
-fasynchronous-unwind-tables -fstack-clash-protection
This is already in Fedora/RISCV for 1+ year.
Signed-off-by: David Abdurachmanov <david.abdurachmanov@sifive.com>
Preparing for language specific compiler flag macros, this is
simply:
perl -pi -e "s:__global_cflags:__global_compiler_flags:g" macros rpmrc
Since this looks like a much bigger change than it actually is, doing
it in a separate step without an associated build.
All ARM version 7 systems support a vector hardware floating point unit and
have the ability to run using the hard floating point ABI (aapcs-vfpv3-d16).
This is the only configuration we support as a v7 target, so we force the
use of hard floating point. This prevents e.g. packages being built with
a armv5tel target on an armv7 system without explicit intent.
Signed-off-by: Jon Masters <jcm@jonmasters.org>
- as per http://fedoraproject.org/wiki/Features/ArchitectureSupport
- set 32 bit intel build arch to i586 on compatible hardware
- set 32 bit sparc build arch to sparcv9 on compatible hardware
- add missing armv7l arch
- set the default build arch to match fedora arm build target
On Fri, 29 Jul 2005, Ulrich Drepper wrote:
> Please find attached the hopefully final changes for the compile flags.
> It's a patch against redhat-rpm-config-8.0.36-1.src.rpm. The changes are:
>
> ~ enable stack protector with minimal size 4 (default is 8, too high
> IMO). Vlad ran some tests on SPEC. SPEC is highly CPU intensive,
> unlike 90%+ of the distribution. Even in those tests the performance
> decrease was below 1%, probably even in the noise. Especially the
> decrease of the minimum size to 4 made no measurable impact.
>
> ~ remove the -fsigned-char flag for ppc. glibc has not been compiled
> with the flag anyway, so if anything changes, we eliminate some bugs.
> The only theoretical issue would be if a library we ship uses CHAR_MAX
> in an interface. I personally haven't seen this for good reasons.
> The only interface I know is localeconv(3) in glibc and this interface
> is now corrected.
>
> ~ minor fix for SPARC
