src/lib/libzstd, branch main

MFV: zstd 1.5.7.

2026-04-08T21:22:45+00:00

MFC after:	2 weeks
Relnotes:	yes

zstd: Move to a new zstd package

2026-01-06T04:24:59+00:00

Zstd is a discrete, self-contained system component.  To match how we
package zlib, bzip2 and xz, move it to its own package, with a separate
lib package.

Add the new package to the minimal set, since this is a core component
that users expect to be installed.

This change adds a new package to the system so, until we have a proper
policy on how to handle this in release/stable branches, it should not
be MFC'd.

MFC after:	never
Reviewed by:	bapt
Sponsored by:	https://www.patreon.com/bsdivy
Differential Revision:	https://reviews.freebsd.org/D53603

Remove residual blank line at start of Makefile

2024-07-15T22:43:39+00:00

This is a residual of the $FreeBSD$ removal.

MFC After: 3 days (though I'll just run the command on the branches)
Sponsored by: Netflix

libzstd: Explicitly define ZSTD_DISABLE_ASM

2023-08-22T20:01:03+00:00

On FreeBSD, ZSTD_ASM_SUPPORTED is defined as 0, but on macOS and Linux
it is defined as 1, yet we don't build any of the assembly sources.
Rather than add them just for bootstrapping on non-FreeBSD, explicitly
define ZSTD_DISABLE_ASM so they're not needed and everything is
consistent.

This fixes building a bootstrap LLVM toolchain on non-FreeBSD amd64 (the
only architecture with assembly available).

Reviewed by:	emaste, imp
Differential Revision:	https://reviews.freebsd.org/D41543

Remove $FreeBSD$: one-line sh pattern

2023-08-16T17:55:03+00:00

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

Disable clang 14 warning about bitwise operators in zstd

2022-02-08T20:46:08+00:00

Parts of zstd, used in openzfs and other places, trigger a new clang 14
-Werror warning:

```
sys/contrib/zstd/lib/decompress/huf_decompress.c:889:25: error: use of bitwise '&' with boolean operands [-Werror,-Wbitwise-instead-of-logical]
                        (BIT_reloadDStreamFast(&bitD1) == BIT_DStream_unfinished)
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```

While the warning is benign, it should ideally be fixed upstream and
then vendor-imported, but for now silence it selectively.

MFC after:	3 days

libprivatezstd: Restrict symbol visibility similar to upstream

2021-01-03T19:26:46+00:00

We have to relax three symbols to dynamically link zstd(1), but the rest
are the same.

pkgbase: Move libprivatezstd from utilities to runtime

2020-11-12T14:04:08+00:00

libarchive depends on it by default and tar uses libarchive.
So on a update :
1/ runtime contain tar
2/ runtime have libarchive in shlibs_required
3/ libarchive packages depends on utilities
4/ utilities depends on runtime
5/ kaboom

All users of libprivatezstd (libarchive related stuff and objcopy/ar)
are already in utilities.

Discussed with: bapt

Only set WARNS if not defined

2020-09-11T13:28:37+00:00

This would allow interested parties to do experimental runs with an
environment set appropriately to raise all the warnings throughout the
build; e.g. env WARNS=6 NO_WERROR=yes buildworld.

Not currently touching the numerous instances in ^/tools.

MFC after:	1 week

Update to Zstandard 1.4.5

2020-05-23T21:23:46+00:00

As usual, the full release notes are found on Github:

  https://github.com/facebook/zstd/releases/tag/v1.4.5

Notable changes include:

* Improved decompress performance on amd64 and arm (5-10%
  and 15-50%, respectively).
* '--patch-from' zstd(1) CLI option, which provides something like a very fast
  version of bspatch(1) with slightly worse compression.  See release notes.

In this update, I dropped the 3-year old -O0 workaround for an LLVM ARM bug;
the bug was fixed in LLVM SVN in 2017, but we didn't remove this workaround
from our tree until now.

MFC after:	I won't, but feel free
Relnotes:	yes