Package Details: aws-lc 1.71.0-4

Git Clone URL: https://aur.archlinux.org/aws-lc.git (read-only, click to copy)
Package Base: aws-lc
Description: General-purpose cryptographic library maintained by the AWS Cryptography team for AWS
Upstream URL: https://github.com/aws/aws-lc
Licenses: ISC, Apache-2.0
Submitter: peregrinus
Maintainer: peregrinus
Last Packager: peregrinus
Votes: 3
Popularity: 0.64
First Submitted: 2025-06-28 14:05 (UTC)
Last Updated: 2026-03-22 19:30 (UTC)

Dependencies (10)

Required by (1)

Sources (2)

Latest Comments

peregrinus commented on 2026-03-22 19:03 (UTC)

Thanks, @5long! I updated the PKGBUILD.

With ENABLE_DIST_PKG=ON libraries and headers are now separated. However, binaries are not (they would cause an error, or overwrite OpenSSL binaries in /usr/bin). I patched that so long and filed a PR upstream.

5long commented on 2026-03-22 11:14 (UTC)

Good news: starting with 1.71.0 there's official soname / shared library support. I've attempted to enable it on this branch: https://github.com/5long/pkgbuilds/commits/haproxy-awslc-soname/aws-lc which works fine with HAProxy -- seemingly, since I don't have real-world production traffic to test with.

5long commented on 2026-02-15 18:24 (UTC)

@peregrinus Big thanks for the detailed explanation and pointing me to the upstream issue. Looks like some fun are to be had.

peregrinus commented on 2026-02-15 15:16 (UTC) (edited on 2026-02-15 15:17 (UTC) by peregrinus)

Hi @5long, it's a pleasure.

The reason for no shared lib (which you could enable yourself if you'd like) is that upstream does not promise ABI compatibility as far as I understand (this was the case some time ago), and they don't provide a SONAME for shared libraries either.

You can enable the building of a shared library, and an experimental SONAME, via build options if you prefer (check the output of cmake -B build -LAH | less in the source dir).

I haven't inspected the HAProxy performance packages, but my guess would be that they statically linked the aws-lc library into their binary. That way they have no ABI concerns (rebuild for every upstream change), and they can optimise the build flags for their own specifications (speed?). I hope this is correct, and that it helps.

This is, in any event, what I intend to do for some softwares.

Instead of building your own HAProxy performance package, you could install a Debian/Ubuntu version? Or, for what it's worth, build your own, and compare it to the Debian/Ubuntu version, and see if it's any different (different compile/build options and optimisations?)? Could be fun!

5long commented on 2026-02-14 20:47 (UTC)

I can see the package has been updated to fix the build issue and kept up-to-update. Thanks for doing the legwork.

There's a non-issue I'm having while building haproxy with aws-lc: currently aws-lc is built as a static library (instead of a dynamic / shared library). I'm kinda curious about the reason of this particular technical choice.

While building haproxy against a static library version of aws-lc does work, Arch has always been building libraries to be dynamic as a general rule (source). The upstream "performance packages" for Debian & Ubuntu also distributes aws-lc as a dynamic library.

5long commented on 2026-02-13 23:07 (UTC)

Failed to build in a clean chroot.

Fixed by adding -Wno-discarded-qualifiers to $CFLAGS (specifically, -DCMAKE_C_FLAGS="$CFLAGS -Wno-discarded-qualifiers"). Although I'm not sure if it's actually "fixed". I just suppressed the warning and the check() did pass with no issues.

soloturn commented on 2026-01-31 02:15 (UTC) (edited on 2026-01-31 02:19 (UTC) by soloturn)

aws-lc seems to be the best ssl implementation out there, i'd really appreciate if it would make it into the arch abs, and would consider it even as a default for arch linux. it is boringssl forked, and added versioned releases. see:

peregrinus commented on 2025-09-08 17:04 (UTC)

If anyone would like to maintain 'aws-lc', please let me know :)