Third-party (i.e. non-pkgsrc) C toolchains (I am using chromebrew)
install to /usr/local, as that is where you can have write access.
With this, a bootstrap on ChromeOS finishes successfully.
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@
The currently implementation of SSP checks simply look for a DT_NEEDED
dependency on libssp, and doesn't yet have a way to check for it being
enabled when it is done via libc.
This appears to be causing issues with pkgsrc GCC attempting to insert
builtins it does not have, because we don't build libssp. unbreaks icu build.
there may be more problems from this issue in the future, but netbsd-7 is
better tested now.
This is only performed if PKG_DEVELOPER and RELRO are in use.
After a suggestion during my talk at BSDCan 2017; thanks!
Also, submitted on tech-pkg@ for review mid-June.
As a next step, it seems this can be extended to libraries, just like the
check for SHLIBS does (from which this is inspired).
Only four platforms, all BSDs, need to resolve "ELF/a.out" into
either ELF or a.out. Calculate it directly in the platform file
and return the value in ${_OPSYS_SHLIB_TYPE} and export that value
in bsd.prefs.mk as ${SHLIB_TYPE}.
Instead of requiring the file(1) tool, we can expect the base
system of those BSDs to have /usr/bin/file, so make use of it
directly.
while ago, but since then any packages that included both curses and
terminfo ended up with conflicting BUILDLINK_TRANSFORM entries, leaving it
to include ordering to determine whether the builtin or pkgsrc curses was
used. This keeps them in sync, at least by default, though ideally we'd
ensure that at an infrastructure level.
to "auto", which will enable cwrappers if the _OPSYS_SUPPORTS_CWRAPPERS
platform variable is set to "yes".
Switch over to cwrappers by default for Darwin, Linux, and SunOS (except when
using the sunpro compiler).
It's going on 10 years since gcc 3.4 and gcc 4.1 were part of DragonFly.
DF Release 4.4 is the earliest with any kind of support and the earliest
possible GCC version is 4.7 there.
simplifies _OPSYS_SYSTEM_RPATH and _OPSYS_LIB_DIRS
permitting lots of stuff using LIBABISUFFIX to work now.
TODO: probably similar for the armv7 platforms as
the pattern '${MACHINE_ARCH}-${LOWER_OPSYS}-gnu${APPEND_ABI}'
seems like it should work for both.
been broken due to NATIVE_MACHINE_ARCH no longer being set to x86_64. Fix
this by introducing HOST_MACHINE_ARCH which refers to the underlying host
architecture rather than bmake's native architecture, thus differentiating
between cross-compiling and multilib.
This is currently only set on Linux as the only OPSYS which currently
requires such a test, but can be expanded to other OPSYS as necessary.
- 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@
It turns out a handful of AIX binutil-like utilities are particular
about type of object files they should examine. Instead of piping
through flags for each utility everywhere, it is easier to just export
'OBJECT_MODE=[32|64]' instead.
From Eric N. Vander Weele.
of software such as Ruby to build on Tiger/PowerPC.
Tested with & without on a G4 with Tiger & Leopard.
It was not needed on Leopard as the linker defaults to a target of 10.5 &
setting it back broke the bootstrap process.
Reviewed by wiz@ long ago.
TOOLS_PATH.readelf is set. This is a PKG_DEVELOPER feature and it's
likely the developer is smart enough to either have it already available
in $PATH or be able to install it (e.g. via devel/binutils) if required.
