The "split" program is not managed by the tools framework. It just has a
wrapper that is placed into the same directory. This is confusing since
intuitively, "split" is a tool like many others.
The "duplicate script for target" warning from Make is therefore correct,
albeit obscure.
Currently, neither the pkgsrc infrastructure nor pkglint check for
allowed tool names.
The TOOLS_CREATE variable is only ever appended to, without checking for
duplicates. In some rare cases, this produces warnings about
doubly-defined make targets. An example is adding USE_TOOLS+=strip to
pkgtools/pkglint:
".../mk/tools/create.mk" line 149: warning:
duplicate script for target ".../work/.tools/bin/strip" ignored
The above line number 149 is zero-based, which in reality means the
duplicate definition is in line 150.
CMAKE_PKGSRC_BUILD_FLAGS
If set to yes, disable compiler optimization flags associated
with the CMAKE_BUILD_TYPE setting (for pkgsrc these come in from
the user via variables like CFLAGS). The default is yes, but you can
set it to no for pkgsrc packages that do not use a compiler to avoid
cmake "Manually-specified variables were not used by the project"
warnings associated with this variable.
The voodoo that checks this now keeps track of which packages caused
what, and in addition to the list FORCED_PKGSRC of packages that have
been forced to non-builtin, it also produces a list FORCED_PKGSRC_REASONS
of the form pkg:causing-pkg{,causing-pkg...}.
(which means that USE_BUILTIN.pkg has been set to no because
USE_BUILTIN.causing-pkg is set to no.)
This could probably just be one list but I'm not sure if anything is
relying on the format of the current FORCED_PKGSRC.
The variable names are typically mentioned in one of these styles:
# Package-settable variables:
#
# VARNAME
# Description
# Package-settable variables:
#
# VARNAME
# Description
Lines that are indented with two tabs contain text. And if one of these
lines starts with a variable name, it is just a coincidence. A practical
example of this happening is in mk/misc/developer.mk 1.24, where PKGNAME
starts a line of description.
This switch is meant to be used by packages requiring an implementation of the
former libusb (as in devel/libusb). The original implementation can be
chosen by setting LIBUSB_TYPE to "native".
The alternative implementation libusb-compat (as in devel/libusb-compat) wraps
libusb1 (in devel/libusb1). This implementation can be chosen by setting
LIBUSB_TYPE to "compat". On NetBSD, it has the advantage of not requiring root
privileges to locate and use USB devices without a kernel driver.
This first part only imports the switch framework itself.
The pkgdb variable generated for pbulk.conf is ${PREFIX}/var/db/pkg but
bootstrap generates by default PKG_DBDIR=${PREFIX}/pkgdb.
This fix add a common PKGDBDIR variable used for both pbulk.conf and
bootstrapkit.
Using variables such as PKGSRC_USE_SSP in package Makefiles to disable SSP does
not work due to the parsing order in bsd.prefs.mk. Even if it did, it's not a
good idea to mix user and package settable variables, and would cause issues in
complex packages where bsd.prefs.mk is included early (e.g. Makefile.common).
Packages can now set {MKPIE,MKREPRO,FORTIFY,RELRO,SSP,STACK_CHECK}_SUPPORTED=no
to correctly disable security features if necessary.
Ninka can be installed from wip/ninka and analyzes each file individually,
thereby providing a much more detailed analysis than the ad-hoc method that
only looks at some COPYING files.
If Ninka is not installed, the naive fallback continues to be used.
Before, the first file that looked like a license file was considered.
The others were completely ignored. This led to a wrong license for
cross/arm-none-eabi-gcc. To prevent these cases in the future, the license
is only guessed if there is exactly one file with a typical license name.
This approach is still naive, but at least a little more precise. Replacing
the guess-license with a determine-licenses is much more complicated
though, since each source code file may have its own license declared, and
handling all these special cases leads to very complex license expressions
(like "gnu-gpl-v3 for all files, except for special.c, which is apache-2.0
or mit). This is very hard to do correctly.
It compares the license file from the package with the available licenses
in licenses/ and shows the diff to the best match.
This will hopefully make it easier for package authors to include the
LICENSE variable in the package Makefile. This variable being missing is
one of the most frequent error messages from pkglint (4187 out of 20044).
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.
