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).
This large commit accomplishes the following:
1) Switch USE_LANGUAGES=ada to require lang/gcc5-aux (gcc 5.4) instead
of lang/gcc-aux (gcc 4.9.2) on gcc.mk
2) Bump affected ports and fix paths as necessary
3) Upgrade devel/gprbuild to the latest release
- No longer requires lang/gnat_util
- gprslave requires gcc6-aux, so it was disabled for now
4) Fix lang/gnat_util but set PKG_SKIP_REASON
- It has no further purpose in the pkgsrc tree
- It has no practical purpose outside of the pkgsrc tree
- Indicate intent to remove from tree in Jan. 2017
5) Set devel/GPS as failed with PKG_FAIL_REASON
- This version of GPS is several years old and at the time they were
strongly tied to compiler.
- Latest release of GPS require gcc6-aux (not available) and several
new and complex dependencies
- maintainer (me) has no interest to continue supporting it
- Leaving GPS in place until Jan 2017 to give another person chance to
upgrade and take over support
- Latest version in FreeBSD Ports Collection as a reference point
modified patch from Rin Okuyama
PR pkg/50722: do not hardcode lang/gcc48 in gfortran.mk
"looks ok, needs docs" - wiz
"it'll do for now, ideally I'd like something more robust and possibly
integrate into gcc.mk's path selection" - jperkin
"no" Do not pass any stack protection flags (the default)
"yes" Pass -fstack-protector
"strong" Pass -fstack-protector-strong
"all" Pass -fstack-protector-all
This allows users to configure the level of stack smashing protection they
require, and ensures consistent behaviour across platforms. Users running
on NetBSD who previously used the option will need to change "yes" to "all"
to match the previous default configuration for that platform.
While here use _WRAP_EXTRA_ARGS to ensure the flag gets passed regardless
of whether the package honours CFLAGS, and support additional wrappers.
Discussed a while back with khorben, and used in production for the SmartOS
2016Q1 package sets with the "strong" option.
- No _GCC_* anything in mk/bsd.prefs.mk;
- No compiler flags in platform files.
Tested again on NetBSD/amd64, with and without cwrappers, with the same
outcome.
With feedback from jperkin@
- Revisit (and rename) support for FORTIFY as PKGSRC_USE_FORTIFY (instead
of PKGSRC_USE_FORT) for easier support outside NetBSD/gcc;
- PKGSRC_USE_SSP is no longer enabled by default when PKGSRC_USE_FORTIFY
is enabled;
- PKGSRC_MKPIE builds executables as PIE (to leverage userland ASLR)
- PKGSRC_USE_RELRO builds with a read-only GOT to prevent some exploits
from functioning.
Tested on NetBSD/amd64 by myself, in every combination, with and without
pkgtools/cwrappers. MKPIE is not supported at the moment with cwrappers.
Also, MKPIE is known to still break a number of packages when enabled (and
actually supported).
Tested on SunOS by jperkin@, thank you!
As discussed on tech-pkg@, the default behavior is not changed, except
where noted above.
ok bsiegert@
The find-prefix infrastructure was required in a pkgviews world where
packages installed from pkgsrc could have different installation
prefixes, and this was a way for a dependency prefix to be determined.
Now that pkgviews has been removed there is no longer any need for the
overhead of this infrastructure. Instead we use BUILDLINK_PREFIX.pkg
for dependencies pulled in via buildlink, or LOCALBASE/PREFIX where the
dependency is coming from pkgsrc.
Provides a reasonable performance win due to the reduction of `pkg_info
-qp` calls, some of which were redundant anyway as they were duplicating
the same information provided by BUILDLINK_PREFIX.pkg.
This is enabled with PKGSRC_USE_SSP in mk.conf(5), as documented there.
Most NetBSD platforms are supported (when compiling with gcc).
After consensus on tech-pkg@.
USE_PKGSRC_GCC_RUNTIME. Fixes check-shlibs when using the GCC runtime
packages as previously the main libraries were being picked up instead
of the runtime ones we'd asked for.
best this does nothing, and at worst it is actively harmful when using
multilib systems. It's possible the mips case is broken too, but I do
not have any hardware to test that on, so for now leave the special mips
MABIFLAG handling intact.
Fixes multilib SunOS builds.
memory and CPU time for certain input. Provide a variable
(CLANG_NO_VALUE_PROPAGATION_PASS) for selectively disabling it in those
places known to trigger it.
