src/gnu/lib/libgcov/Makefile, branch releng/12.4

Convert gnu to using SRCTOP

2017-03-12T18:59:16Z

Prefer SRCTOP over CURDIR/../../contrib, etc. However, retain the "up one level" instances of ../ because they are really relative to this part of the tree and not a means to find the root of the tree. As such, it's better to leave them since that further the goal of being able to move directories if watned to in the future. Differential Revision: https://reviews.freebsd.org/D9932 Sponsored by: Netflix Silence On: arch@ (twice)

When MAKEOBJDIRPREFIX points to a case-insensitive file system, the

2016-09-24T15:11:27Z

build can break when different source files create the same target files (case-insensitivity speaking). This is the case for object files compiled with -fpic and shared libraries. The former uses an extension of ".So", and the latter an extension ".so". Rename shared object files from *.So to *.pico to match what NetBSD does. See also r305855 MFC after: 1 month Sponsored by: Bracket Computing Differential Revision: https://reviews.freebsd.org/D7906

Follow-up r297842: Rework header generation to fix always rebuilding.

2016-04-18T18:13:58Z

This reworks the handling of common headers to just include the needed logic rather than invoke MAKE. This avoids the problem listed in r297842 and avoids other dependency tracking issues. Pointyhat to: bdrewery Reported by: Nikolai Lifanov Sponsored by: EMC / Isilon Storage Division

META_MODE: Avoid changed build command every build.

2016-04-12T02:45:19Z

Because the file is generated with -f using another Makefile, 2 different Makefiles are trying to handle the .meta file for the target. The obvious .NOMETA_CMP or .NOMETA on the ${MAKE} targets don't work as they are very limited in scope in bmake. Using .PHONY fixes the problem and ensures that the ${MAKE} command is always ran to check if it is outdated in the sub-make. An example of the problem in gnu/lib/libgcc (with make -dM): /usr/obj/root/git/freebsd/gnu/lib/libgcc/tm.h.meta: 2: a build command has changed TARGET_CPU_DEFAULT="" HEADERS="options.h i386/biarch64.h i386/i386.h i386/unix.h i386/att.h dbxelf.h elfos-undef.h elfos.h freebsd-native.h freebsd-spec.h freebsd.h i386/x86-64.h i386/freebsd.h i386/freebsd64.h defaults.h" DEFINES="" /bin/sh /root/git/freebsd/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh tm.h vs (cd /root/git/freebsd/gnu/lib/libgcc; make -f /root/git/freebsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/root/git/freebsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/root/git/freebsd/gnu/lib/libgcc/../../../contrib/gcc tm.h) Skipping meta for tm.h: .NOMETA (cd /root/git/freebsd/gnu/lib/libgcc; make -f /root/git/freebsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/root/git/freebsd/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/root/git/freebsd/gnu/lib/libgcc/../../../contrib/gcc tm.h) `tm.h' is up to date. Sponsored by: EMC / Isilon Storage Division

Remove MK_ARM_EABI, the armeb issues have been fixed. The code to support

2014-10-01T08:26:51Z

the oabi is still in the tree, but it is expected this will be removed as developers work on surrounding code. With this commit the ARM EABI is the only supported supported ABI by FreeBSD on ARMa 32-bit processors. X-MFC after: never Relnotes: yes Differential Revision: https://reviews.freebsd.org/D876

Make sure that the sub-makes for unwind.h start from the CURDIR

2014-06-24T22:15:27Z

(/usr/src) tree rather than the OBJDIR (/usr/obj) tree. This fixes broken incremental builds with the canonical MAKESYSPATH workaround of .../share/mk. This is a gross kludge.

Use src.opts.mk in preference to bsd.own.mk except where we need stuff

2014-05-06T04:22:01Z

from the latter.

Spell NO_PROFILE= as MK_PROFILE=no.

2014-04-25T19:25:26Z

Add compiler support for the ARM EABI.

2013-01-17T05:56:28Z

ARM EABI support is disabled by default and can be enabled by setting WITH_ARM_EABI when building, however only the kernel-toolchain target will work with this flag until the rest of the support is added.

Compile libgcov without stack protection. It can be linked into

2009-10-25T15:52:31Z

both static and dynamic binaries compiled with or without stack protection and should not depend on libssp_nonshared.a symbols. Discussed with: kib PR: bin/139052