There are only a few releases where this appears to work, and the commit logs
show this to be a complete pain to get working. I've now confirmed it's also
broken on Big Sur where ksh simply segfaults on both x86_64 and arm64.
This may have been marginally useful in the past, but we now have cwrappers to
provide a much bigger performance improvement, and so this hack was only used
during bootstrap to build a small number of packages anyway.
It's currently impossible to run system binaries inside an arm64 chroot, even
with SIP turned off, so the only way to build is to use an x86_64 chroot and
effectively cross-compile to arm64.
most of these simply extend matching from "aarch64" to "aarch64eb"
in various forms of code. most remaining uses in pkgsrc of
"MACHINE_ARCH == aarch64" are because of missing aarch64eb support,
such as most of the binary-bootstrap requiring languages like rust,
go, and java.
no pkg-bump because this shouldn't change packages on systems that
could already build all of these.
For example, the recently release macOS 11.2 does not ship a 11.2 SDK, but
continues to use the compatible 11.1 SDK. This now works correctly without
having to enable OSX_TOLERATE_SDK_SKEW.
These should only be added for releases within the same major version where we
can guarantee compatibility.
breakage for users who have other package managers that use /var/db/pkg
(Reported by Frederic Cambus on FreeBSD, OpenBSD)
Adjust warning: specifying PKGDB_DIR in mk.conf should be sufficient
for building packages for the compatibility pkgdb location.
This is still an error message, because:
- While we can handle the existing references of PKGDB_DIR, new ones
might be created.
- It is a minor inconvenience to people building packages from source.
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.
Native tar on NetBSD <=8 (and later, if MKBSDTAR is no) does not
handle archive formats increasingly being seen in pkgsrc. bsdtar
("libarchive tar") does, and is natively provided on NetBSD >=9.
pkgsrc already has a mechanism to use /bin/tar as the bsdtar tool when
it is bsdtar, so this change should not cause anything different on
NetBSD >= 9. On <=8, it will depend on archivers/bsdtar, which can
be built without using an extract tool, and which will then be broadly
usable.
As broadly discussed over multiple days on tech-pkg.
Running "/lib/x86_64-linux-gnu/libc.so.6 --version" on Debian unstable
inside WSL says:
GNU C Library (Debian GLIBC 2.29-9) stable release version 2.29.
In this case, there is a simple period, not a comma after the version
number.
Platform support is determined by _OPSYS_SUPPORTS_CTF from mk/platform, the
user enables support by setting PKGSRC_USE_CTF=yes, and packages can
explicitly disable support with CTF_SUPPORTED=no or skip certain files with
CTF_FILES_SKIP.
The path to ctfconvert is configured via TOOLS_PLATFORM.ctfconvert.
If all of the requisite variables are enabled, a compiler-specific debug flag
is passed via the wrappers to ensure we have DWARF information to convert,
_INSTALL_UNSTRIPPED is explicitly defined to avoid binaries being stripped
prior to conversion, and the conversion is performed during the install stage.
It is recommended that users who enable the feature also set STRIP_DEBUG=yes
to reduce the final binary size once the conversion has been performed.
This has been used for the past year in Joyent SmartOS builds. FreeBSD is
marked as supported but is untested.
