lang/gcc8 has patches for NetBSD/aarch64 and lang/gcc10 has support mostly
upstreamed. Nobody seems interested in fixing gcc9, but the pkgsrc
logic defaults to it when the system compiler is GCC 9 which leads to
broken fortran packages. Let's just skip forward to gcc10.
PostgreSQL 13 contains many new features and enhancements, including:
* Space savings and performance gains from de-duplication of B-tree index entries
* Improved performance for queries that use aggregates or partitioned tables
* Better query planning when using extended statistics
* Parallelized vacuuming of indexes
* Incremental sorting
Install the new interchangeable BLAS system created by Thomas Orgis,
currently supporting Netlib BLAS/LAPACK, OpenBLAS, cblas, lapacke, and
Apple's Accelerate.framework. This system allows the user to select any
BLAS implementation without modifying packages or using package options, by
setting PKGSRC_BLAS_TYPES in mk.conf. See mk/blas.buildlink3.mk for details.
This commit should not alter behavior of existing packages as the system
defaults to Netlib BLAS/LAPACK, which until now has been the only supported
implementation.
Details:
Add new mk/blas.buildlink3.mk for inclusion in dependent packages
Install compatible Netlib math/blas and math/lapack packages
Update math/blas and math/lapack MAINTAINER approved by adam@
OpenBLAS, cblas, and lapacke will follow in separate commits
Update direct dependents to use mk/blas.buildlink3.mk
Perform recursive revbump
pkgsrc changes:
---------------
* Remove the pkgconfig file generation since the version of libusb1 cannot
be obtained by parsing LIBUSB_API_VERSION from libusb.h (e.g. FreeBSD
provides 0x01000102 for 1.0.13 and Arch provides 0x01000107 for 1.0.23).
* At least FreeBSD, Debian and Arch provides a libusb-1.0.pc file for
their native implementation. Link this file to ${BUILDLINK_DIR}.
* Add logic in mk/buildlink3 to find pkgconfig files in common pkgconfig
directories (for at least FreeBSD, Debian and Arch).
These no longer support being executed via a symlink, failing with errors
such as:
xcode-select: Failed to locate 'gmake', and no install could be requested
This breaks the entire .tools/bin directory, so we just have to avoid them
and use tools from pkgsrc instead.
It's likely a lot more will need to be added to this list, but this is
enough to get devel/cmake building at least.
This is required for find-libs.mk to continue detecting the presence of
libraries supported by the system. It's definitely not ideal, and only
still works because Apple happens to ship .tdb files for each library, and
these are found via the current "lib${_lib_}.*" glob.
Patch taken from sjmulder@, I only limited it to Big Sur for now in case
there are issues using the SDK directory on older releases.
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.
This means that from now on, there is no global setting to switch off
this redundancy check. Individual SUBST classes can still set their own
SUBST_NOOP_OK.<id> in order to ignore no-op filename patterns.
The current bulk builds do not show any build failures that are caused
by this, which means that really almost all packages have been migrated.
-Werror=implicit-function-declaration, which will be great someday when
we're ready for it. Until then, on macOS, detect this situation and tell
the cc wrapper to prepend -Wno-error=implicit-function-declaration.
Taking mail/qmail as our example, this fixes the build on Catalina
with "Apple clang version 12.0.0 (clang-1200.0.32.2)". Adding
-Werror=implicit-function-declaration to CPPFLAGS or CFLAGS (in
mk.conf or on the command line) re-fails the build, as expected, with
a pile of "error: implicit declaration of function". Also as expected,
a full -Werror fails earlier on one of the many other problems with
qmail's code.
For clang on non-macOS platforms, no change.
clang-and-wrapper-ok: joerg@
during-the-freeze-ok: gdt@
The show-all code is mostly line noise, therefore it is all the more
important to provide at least a few hints to a potential reader, by
using descriptive variable names for the iteration variables:
g => grp
c => cat
v => var
w => width
x => word
I had been confused by the printf commands since some of them used '\n'
and some used '\\\n', which seemed as if there were some quoting issue
that would make it necessary to double the backslashes.
This assumption was wrong though. The printf commands for the
single-valued variables use the normal '\n', while the lines for the
multi-valued variables end with a real backslash in the output, to
mimick the continuation lines in makefiles.
As a hint that the '\\\n' means backslash + newline, add single quotes
between the two characters.
The previous code relied on the exact implementation of Var_Parse in
bmake, and that it does not issue any error messages in case of $$ in
variable modifiers.
In variable modifiers, a $ is escaped using \$, not $$, as documented in
the manual page.
At the time when I wrote the previous version with the _SHOW_ALL.d4 and
_SHOW_ALL.d8 hacks, I did not know about the backslash escaping rule,
and I just added dollar signs until everything seemed to work. I
couldn't explain why it worked though, which is not surprising since the
code was using an undocumented implementation flaw of bmake.
The previous shell script version's runtime was quadratic against the
number of distfiles to verify. Historically this has not been an issue,
with usually only a handful of files per package. However, with the
introduction of Go modules the number of distfiles used by a single
package can be very high.
For example, in an upcoming update of www/grafana to version 7.1.5, the
number of GO_MODULE_FILES is 821. Running 'bmake checksum' takes:
real 18m20.743s
user 17m27.975s
sys 0m49.239s
With the awk code, this is reduced to a far more sensible:
real 0m4.330s
user 0m3.241s
sys 0m0.875s
The script has been written to emulate the previous version precisely,
preserving the same output and error messages and supporting all of its
behaviour, with the one exception that previous exit values of 128 have
been changed to 3, in order to avoid any potential signed 8-bit issues.
The one change in the pkgsrc infrastructure is that the mk/fetch/fetch
script no longer sets a working default value for ${CHECKSUM}. This is
not a problem in a pkgsrc environment as all of the required variables
are set correctly, but if there happen to be any users who are using
this script in a standalone environment, they will need to set it
accordingly. This was probably required in many situations previously
anyway, as none of the script's environment variables were set, and
trying to support this would be fragile at best.
At some point CRAN added the https protocol to its repositories, but
this was never reflected in MASTER_SITE_R_CRAN. Add analogues for
all the http sites with responsive https servers.
There won't (or at least should never!) be any files under share/ or man/ that
require conversion for CTF or debug support, so set sensible defaults for both
CTF_FILES_SKIP and STRIP_FILES_SKIP. Further additions are welcome.
While here rearrange the ordering of the debug skips to match CTF and deliver
a small performance improvement by avoiding unnecessary file tests.
Combined, these reduce the runtime for "make install-ctf install-strip-debug"
in lang/rust down from wall/user/sys 10m33s/2m34s/9m30s to 1m13s/0m46s/1m4s.
