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.
When not using cwrappers, so far PKGSRC_MKPIE was only automatically
applied when linking using gcc(1) (when enabled). This is now also the
case for packages using ld(1) to link executables.
This is only relevant for PKGSRC_MKPIE. It partly reflects a fix that
was committed to the cwrappers for MKPIE, where the "-pie" flag was
automatically added in spite of the linker not actually creating an
executable.
This solves an issue with the command sink component of the MKPIE
wrapper for GCC, where the contents of the _MKPIE_CFLAGS.gcc and
_MKPIE_LDFLAGS.gcc variables was guessed. It is now communicated to
cmd-sink-mkpie-gcc through the environment instead.
The cmd-sink-mkpie-gcc component for PKGSRC_MKPIE support on GCC was
lagging behind the generic one. This makes sure it cannot happen again,
by invoking the generic sink right away.
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@
Match cwrappers' expectations and place an argument per line in the
configuration. Tokenize the arguments when writing the configuration
instead of inside cwrappers.
This should fix PKGSRC_MKPIE.
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.
This adds a detection for Chrome OS and Chromium OS based on /etc/lsb-release,
which sets LOWER_VENDOR, like for other Linux distros. It also sets OS_VARIANT
to the value of LOWER_VENDOR, so we can have conditionals for ChromeOS. It is
missing some things that are silently assumed to be part of Linux base
systems, such as POSIX attr support, NIS and more.
ok jperkin@
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.
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.
Enhance the reduce-depends.awk script to reduce a larger set of
dependencies into a single dependency. The patterns representing
intervals of version numbers (can be open-ended) are of the form:
pkg>lower
pkg>=lower
pkg<upper
pkg<=upper
pkg>lower<upper
pkg>lower<=upper
pkg>=lower<upper
pkg>=lower<=upper
These patterns are now condensed into a single dependency of the
same form. For example, given the following patterns:
pkg>=1.0
pkg>2.0
pkg<3.0
pkg<=4.0
pkg>=2.5<3.5
the reduced pattern becomes:
pkg>=2.5<3.0
Add the test script used to help with refactoring and adding the
new feature to the script.
This is a mostly complete rewrite of the script; change the
license to the standard 2-clause BSD license used by TNF.
While it would be useful, the current implementation has not been
updated even to use 'cvs add' instead of 'cvs import' (policy change
in 2012). Use the import-package.sh script currently residing in wip/
instead.
