GFORTRAN_VERSION should match CC_VERSION as closely as possible for
ABI compatibility. This update tries to match GFORTRAN_VERSION
to CC_VERSION if the base compiler is GCC. If base compiler is not
GCC, default to a mainstream version likely to work with base clang/llvm.
A default installation of GCC doesn't install bin/cc but only bin/gcc.
Adding bin/cc is only done by the pgksrc packages, not by the upstream
package.
The previous strategy of just checking whether ${GCCBASE}/bin/${CC:[1]}
exists did not work in such a situation. Therefore, if CC still has its
default value from sys.mk, that is changed to the intended gcc, which
then detects the base GCC properly.
See https://mail-index.netbsd.org/pkgsrc-users/2019/09/07/msg029329.html.
See https://mail-index.netbsd.org/tech-pkg/2019/09/18/msg021976.html.
This way we don't inadvertently tell a native dependency that it is
supposed to be compiled with the cross-compiler.
No functional change intended for USE_CROSS_COMPILE=no.
When a Makefile fragment contains $0, this means a Makefile variable, not
a shell or AWK variable.
The bug in ccc.mk survived unnoticed for almost 15 years. The bug in
gnu-configure.mk for MirBSD got only half as old.
Platform support is determined by _OPSYS_SUPPORTS_CTF from mk/platform, the
user enables support by setting PKGSRC_USE_CTF=yes, and packages can
explicitly disable support with CTF_SUPPORTED=no or skip certain files with
CTF_FILES_SKIP.
The path to ctfconvert is configured via TOOLS_PLATFORM.ctfconvert.
If all of the requisite variables are enabled, a compiler-specific debug flag
is passed via the wrappers to ensure we have DWARF information to convert,
_INSTALL_UNSTRIPPED is explicitly defined to avoid binaries being stripped
prior to conversion, and the conversion is performed during the install stage.
It is recommended that users who enable the feature also set STRIP_DEBUG=yes
to reduce the final binary size once the conversion has been performed.
This has been used for the past year in Joyent SmartOS builds. FreeBSD is
marked as supported but is untested.
This is based on the decision The NetBSD Foundation made in 2008 to
do so, which was already applied to src.
This change has been applied to code which is likely not in other
repositories.
ok board@, reviewed by riastradh@
It currently tackles two problems:
- gcc(1) hard-coding full paths in debugging information (with one
caveat at the moment)
- ar(1) hard-coding user IDs in archive headers
This allows packages built from the same tree and options to produce
identical results bit by bit. This option should be combined with ASLR
and PKGSRC_MKPIE to avoid predictable address offsets for attackers
attempting to exploit security vulnerabilities.
This is still disabled by default, and only supports NetBSD so far.
As discussed on tech-pkg@
This makes sure a simple "cc -o hello hello.c" will still build a valid
executable. It does not let us detect when CFLAGS or LDFLAGS are
ignored anymore, but it is legitimate for packages to expect it to work
without any additional parameter.
ld(1) does not expect "-fPIC" but it seems to be ignored by our wrappers
in this case, so no disruption is expected there.
We can't rely on _GCC_VERSION as an accurate indicator of the GCC version,
as when using a pkgsrc GCC it will be set to 0 until the pkgsrc GCC is
available and we can detect its version. Instead, move the logic later to
after CC_VERSION is set and use that instead.
This is based on a patch submitted on 16/04/2017 on tech-pkg@ and
adapted by joerg@ for pkgtools/cwrappers. It only consists in the
missing part to actually generate PIE executables with cwrappers if
configured to do so (currently disabled by default). The aim is really
to produce safer binaries where ASLR is in use.
This part in pkgsrc is only supported on NetBSD (x86) with GCC at the
moment.
Tested on NetBSD/amd64, with and without cwrappers, with and without
PKGSRC_MKPIE (all four combinations).
ccache needs to call real compiler and it detects it with looking in $PATH.
In case of usage of /usr/local/bin/clang as the desired pkgsrc $CC option,
it will be shadowed by /usr/pkg/bin/clang if someone will build it in as a
package. Workaround the problem with setting CCACHE_PATH through
PKGSRC_MAKE_ENV. Little bit overzelaously set it to
${CCPATH:H}:${CXXPATH:H}:${CPPATH:H}, just in case that they might be in
different paths. To ensure that they are not shadowed in narrow cases,
there is an option to rename clang to xclang or similar and use it this
way in $PKG_CC.
While there, introduce new user settable option: CCACHE_LOGFILE.
If set, ccache logs to file specified in ${CCACHE_LOGFILE:Q}.
+# CCACHE_LOGFILE
+# If set to a file path, ccache will write information on what it is
+# doing to the specified file. This is useful for tracking down
+# problems.
This fixes another set of problems building large projects like Clang, LLVM
with ccache.
Sponsored by <The NetBSD Foundation>
The new options are, for FORTIFY:
"no" Do not pass any flags for FORTIFY
"weak" Pass -D_FORTIFY_SOURCE=1
"strong" Pass -D_FORTIFY_SOURCE=2
This allows users to reduce the level of FORTIFY specified if necessary
or desired. The previous setting as "yes" is now equivalent to "strong"
(the default when enabling).
The new options are, for RELRO:
"no" Do not pass any flags for RELRO
"partial" Pass -Wl,-z,relro
"full" Pass -Wl,-z,relro -Wl,-z,now
This allows users to reduce the level of RELRO specified if necessary or
desired. The previous setting as "yes" is now equivalent to "full" (the
default when enabling).
This is intended to match the changes committed by jperkin@ (for SSP)
after our discussion a (long) while back.
No functional change intended (with the settings supported so far).
