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.
OS X has been upgraded and Xcode hasn't been -- try again without
specifying the version. This (1) works better and (2) gives a better
error message when it doesn't. From Markus Mayer in PR pkg/50317.
If not, set _OPSYS_SUPPORTS_SSP=no during bootstrap and in mk.conf.
Do SSP detection on "SunOS", and let mk/platform/SunOS.mk's default
"yes" be overridden in mk.conf.
No change to generated mk.conf on NetBSD 8 or CentOS 6. Fixes bootstrap
on Tribblix.
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.
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@
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.
This appears to be causing issues with pkgsrc GCC attempting to insert
builtins it does not have, because we don't build libssp. unbreaks icu build.
there may be more problems from this issue in the future, but netbsd-7 is
better tested now.
