This behaviour is probably due to a past behaviour of clang, where it
always emitted frame pointer code.
This is no longer true for clang on netbsd, and I don't think it was true
for GCC.
Meanwhile, this flag bleeds into pkgsrc where it breaks random packages,
requiring workarounds like lang/ruby*-base/hacks.mk.
is not changed do that instead of scanning for a single character delim ':',
it scans for "?:". This is because !empty(COMPILE.c:M*-pg*) contains a ':'.
(because the compiler complains), to use a match with the compile flags
and *pg*, instead of using a match to a target suffix (which is NetBSD
build-specific). Pointed out by phone@.
so it performs the test at the time the rule is invoked. We can't
use a ".if defined" test because that would be tested at the time the
sys.mk file is parsed, which may be before CTFCONVERT has been set by
bsd.own.mk.
Remove the now-unnecessary assignment "CTFCONVERT ?= : ctfconvert",
and the similar assignment to CTFMERGE. Now the build logs are not
cluttered by many unnecessary invocations of the ": ctfconvert ..."
"-Os" was specfied when gcc 4.5.x was imported and the commit log says
"-O2 produces much bigger code with gcc 4.5 than it did with gcc 4.1"
but "-Os" disables most inline declarations and makes some applications
much slower. "-O2 -fno-reorder-blocks" seems enough to reduce sizes
and disabling -freorder-blocks wouldn't cause particular performance
impact on ancient m68k machines with small cache memories.
See my post on port-m68k@ for more details:
http://mail-index.NetBSD.org/port-m68k/2014/06/22/msg000488.html
No objection in the thread and "seems fine to me" from mrg@.
Don't test for /usr/bin/ctfconvert or /usr/bin/ctfmerge -- that is
completely bonkers and breaks the build if the host's ctfconvert and
ctfmerge are too old.
Strip the broken conditionals in the .c.o &c. rules.
bsd.own.mk will override CTFCONVERT and CTFMERGE with TOOL_CTFCONVERT
and TOOL_CTFMERGE if MKCTF=yes.
XXX The way CTFCONVERT and CTFMERGE are integrated into the rules is
bogus -- it is not safe to interrupt them. We need some intermediate
object to do this right.
Please let me know if I broke anything with this -- I am not an elvin
or dwarven wizard, nor a dtrace expert. But this has been breaking
builds for ages now and nobody else seems to want to do anything
about it.
Honour this for dependency processing in bsd.dep.mk. Switch i386 and
amd64 assembly to use ISO C90 preprocessor concat and drop the
-traditional-cpp on this platform.
so handle it in each Makefile rather than sys.mk.
These ICEs might be related with GCC Bugzilla Bug 32424
which is not resolved yet even in the upstream.
