This is needed by packages that require hand-holding in building PIE. Also a
post-build check for MKPIE is performed by default when PKG_DEVELOPER=YES.
Improves language and mirrors LD_TOXIC_PATH nomenclature available on at
least the SunOS dynamic linker. The previous name is retained for now
for compatibility, even though I get the feeling I'm the only person who
is actually using this feature.
This variable appears to be incorrect as "_PKGSRC_USE_RELRO" is set in
bsd.prefs.mk. This was causing RELRO_SUPPORTED=no to not function as intended
in lang/go/go-vars.mk
ok'd by jperkin
The new release of macOS removes system libraries from the file system, only
providing access to them via a linker cache and dlopen(). This obviously
breaks many assumptions about how libraries work on Unix systems, and so we
unfortunately need to cripple various checks when running on those systems.
Introduce DARWIN_NO_SYSTEM_LIBS which, when defined, will trigger alternate
behaviour in the infrastructure. Currently this is in two places:
* In CHECK_SHLIBS, skip any path beginning with /usr/lib.
* In registered package metadata, any path beginning with /usr/lib is
removed from REQUIRES.
The former fixes all package builds, while the second will be necessary for
package managers such as pkgin, as they will no longer be able to verify that
those files are available on the target system.
This is obviously a gross hack, and removes our ability to ensure that the
target system is suitable for the packages we are attempting to install, but
Apple have left us with no alternative, and users will unfortunately be left
to find out at runtime instead.
It's likely this will need to be extended to /System/Library paths too, but
this is required first to actually get packages building before we can start
running bulk builds.
Just in case any of these tools defines some command line arguments. The
correct path had already been used before since both env and sh are added
to USE_TOOLS in bsd.pkg.mk.
Right now, users who install the pkg-vulnerabilities database find that
the vast majority of packages fail to build, penalizing them too severely.
Package auditing can still be done via "pkg_admin audit".
Alternatively, the previous behaviour can be restored with
ALLOW_VULNERABLE_PACKAGES=no in mk.conf.
Additionally, bmake-ify the check.mk logic. It was easier to do this,
as the package relied on a single long ${RUN} command.
Proposed on tech-pkg, with no objections to the idea of changing the
default, just the method of doing so.
A commonly occuring scenario is that a package patches the configure
script, but that the corresponding configure.in contains shell code that
is not portable. In cases like these, configure.in is typically not used
during the build, therefore there is no need to check it for portability.
This also applies to all other combinations where a file is patched and
the corresponding file.in contains unportable shell code.
Before, adding "Binary file matches" (including the quotes) to
CHECK_WRKREF_EXTRA_DIRS led to a syntax error. Adding this string is so
obvious that it should have been added a long time ago already.
These appear to have been cargo culted around for a while, don't even have
anything to do with DESTDIR mode, and are completely useless. Simplify the
logic a little while here. Noticed by rillig@.
When all files are skipped, the tool dependency is not added as well.
This allows packages to skip the check without defining the user-settable
variable CHECK_PERMS.
Since the portability checks are concerned about bashisms, it doesn't make
sense to apply them to programs that will later be run in bash anyway.
Suggested by gdt via private mail.
These files typically come with a corresponding Makefile.in file, and the
same portability issue is in the .in file as well. For building the
package it is only necessary to patch the .in file. Patching the .am file
as well would mean additional work for the pkgsrc package maintainer.
Nevertheless, such fixes should be reported upstream. The upstream
maintainer is more interested in a patch for Makefile.am, since the .in
file is only generated.
Suggested by wiz via private mail.
Before, file names that start or end with spaces were trimmed by read(1),
as specified by POSIX 2004 and POSIX 2018.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/read.html
This edge case bug had been present since the very beginning of this
code, in November 2006.
Filenames containing backslashes or newlines are still not supported, and
probably never will be intentionally supported.
Up to now, these files had been skipped because they didn't start with a
#! line. Still, they contain shell programs, therefore it makes sense to
check them.
Since several years, the portability check only checks for shell files.
Instead of opening each extracted file to see whether it is a shell file,
it is more efficient to filter the files based on their names. This saves
a few system calls and in the case of lang/gcc9, half of the total
running time.
The file extensions to be excluded from the check have been sorted by
their count in the PLISTs. This data does not accurately represent the
source files of the package, but it's better than nothing.
Since pkgtools/check-portability is not installed by default, it will not
harm any existing pkgsrc setup. To activate it, it has to be installed
manually. After a testing phase, it will be installed whenever
PKG_DEVELOPER is set.
have a GNU_RELRO flag. (they won't because it doesn't do anything to them).
Should eliminate some of the need for CHECK_RELRO_SKIP, especially for some
Go binaries.
Skip any lines of otool output that do not start with a tab, ensuring we
only check valid files and ignore e.g. shell scripts. Older versions of
otool would simply print no output on such files, whereas newer releases
print "is not an object file".
