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.
