libacl import options to address -fPIC and other similar issue by Nikhil2206 · Pull Request #515 · eclipse-score/baselibs

Nikhil2206 · 2026-08-26T06:53:57Z

This is Just draft PR to compare and finalized the approach to import libacl in baselib repo

Replace prebuilt acl `.deb` with a hermetic, source-built `libacl`

Problem: score_baselibs consumed acl as an architecture-pinned Ubuntu .deb (libacl1-dev). This repeatedly broke on non-Ubuntu targets and on aarch64 (missing -fPIC, arch/toolchain mismatches) — tracked as SWP-278650 (#172, #496, #78).

Fix: Vendor upstream acl-2.4.0 source and compile it with this repo's own toolchain instead, so PIC/ABI can never drift from the rest of the build, on any target this repo supports (Ubuntu/AutoSD/Elektrobit, x86_64/aarch64) — no per-distro .deb needed.

What's included

MODULE.bazel: replaced the two deb() rules (acl-deb, acl-deb-aarch64) with a single archive() rule (acl-src) pulling the sha256-pinned acl-2.4.0 tarball.
acl.BUILD / acl_sources.bzl: cc_library(:acl) compiling only the plain POSIX ACL subset actually needed by acl_impl.cpp (excludes the GPL-2 CLI tools and the unused _at/perm_copy_* files).
config.h: hand-written stand-in for acl's autoconf-generated config.h, scoped to this repo's one supported target class (glibc, 64-bit, little-endian Linux).
- ENABLE_NLS is the one genuine configure-time option (gates gettext() in include/misc.h), so it's exposed as a real Bazel flag (bool_flag + config_setting, --@score_baselibs//third_party/acl:enable_nls) instead of being hardcoded.
check_config_drift.py (config_drift_test): fails the build if (a) a vendored source references an autoconf-style macro (HAVE_*, ENABLE_*, ...) not accounted for in config.h, or (b) a vendored file's header claims the GPL rather than the LGPL — both catch drift automatically on future acl version bumps.
cc_shared_library(:acl_shared): builds libacl as a real shared object, giving consumers a straightforward LGPL-2.1 §6(b) compliance path (swap the .so without relinking). Static linking (:acl) is now visibility-restricted to the one wrapper that needs it at compile time (score/os:acl); every other consumer must go through :acl_shared + dynamic_deps. score/os/test:acl_test and score/os/utils/acl:unit_test were switched to dynamic linking as the first (and currently only) consumers.
NOTICE / acl-lgpl.txt: added LGPL-2.1 attribution and license text for the vendored code.
.bazelrc: demoted -Werror for external/.*acl-src.*, since the vendored upstream source doesn't meet this repo's strict warning bar (e.g. -Wcast-qual).
libacl_import_options.md: design doc comparing this approach (build-from-source) against a hermetic sysroot alternative, grounded in the actual implementation.

Validation

Built and tested on both bl-x86_64-linux and bl-aarch64-linux (aarch64 via qemu); verified via ldd/runfiles inspection that the dynamic-linked test targets pull in libacl_shared.so at runtime with no static duplication; confirmed the visibility restriction blocks unauthorized static consumers and config_drift_test/GPL-check both pass.

github-actions · 2026-08-26T07:09:36Z

Documentation preview for this pull request is available at:
pr-515: https://eclipse-score.github.io/baselibs/pr-515/

4og · 2026-08-26T12:55:44Z

+  handle their native build systems/autoconf quirks); becomes something this
+  repo now owns and must patch/update over time; still need libc/system
+  headers (e.g. `sys/capability.h`) to match target consistently.
+


Regarding the libcap. There is https://registry.bazel.build/modules/libcap/2.27.bcr.2/overview. Can we use it instead of pulling a deb? I'm not entirely sure it's the same thing or it's a different implementation

Maybe we can also add the acl lib to BCR?

I looked again. The BCR has the same libcap we're using, but a very old version. We can raise a PR in BCR to add a newer version

we could think of BCR approach, but this might look overkill for baselib purpose because

we likely need to maintain that per lib,

could have delayed merges, maintainer may or may not like this

harder to audit for a safety case, and re-verification is needed on every module version bump, on someone else's release cadence.

i think keeping build and config controll to baselib look relatively safer

4og · 2026-08-26T13:03:19Z

+  this repo; slower to iterate; still needs a strategy per distro if
+  AutoSD/Elektrobit need different library builds (e.g. musl vs glibc,
+  different ABI).
+


Another con here:

users of baselibs may use their own toolchain that could be lacking the appropriate sysroot configuration

Nikhil2206

@nradakovic
could you please share your openion on this topic,
specifically option 4 using build from source approach, we are likely to use, I am currently verifying it in reference integration

4og · 2026-09-02T15:30:56Z

+
+# Bazel-native equivalent of upstream acl's `./configure --enable-nls`: gates
+# whether include/misc.h's `_()` macro (see @acl-src//:acl) routes through gettext().
+bool_flag(


Why is this flag needed? Do we really want to give a user a way to control it?

4og · 2026-09-02T15:33:34Z

 build --per_file_copt=external/.*google_benchmark.*@-Wno-error
+# acl is vendored third-party source (see third_party/acl/acl.BUILD); it does not
+# meet this repo's strict warning bar (e.g. -Wcast-qual), so demote its warnings.
+build --per_file_copt=external/.*acl-src.*@-Wno-error


We should find another way to solve this as acl is non-dev-dependency. @nradakovic, any options here other that creating a yet another transition?

4og · 2026-09-02T15:42:56Z

-        "//conditions:default": "@acl-deb//:acl",
-    }),
+    actual = "@acl-src//:acl",
+    visibility = ["@score_baselibs//score/os:__pkg__"],


These two aliases looks wrong.
The score/os is the only user of libacl and here it links statically to it. What is purpose of acl_shared then?

My expectation nobody is linking to the static lib other then for purposes of constructing a shared library. I.e. score/os users should link to the shared lib only

4og · 2026-09-02T15:45:55Z

-    name = "acl-deb-aarch64",
+# acl is vendored from upstream source instead of a prebuilt, arch-pinned Ubuntu .deb
+# (see third_party/acl/acl.BUILD and score/os/BUILD's `:acl` target) to avoid the
+# recurring -fPIC/arch breakage tracked by SWP-278650 (eclipse-score/baselibs#172, #496, #78).


Avoid mentioning any internal tickets in code.

I was trying it but, it got missed somehow

4og · 2026-09-02T15:47:01Z

+
+third_party/acl vendors the plain POSIX ACL portion of libacl's source (excluding
+acl_delete_def_file_at and perm_copy_fd/perm_copy_file) from acl 2.4.0 [2],
+compiled directly as a score_baselibs cc_library instead of installing a prebuilt,


Mentioning ubuntu deb packages looks wrong here

Nikhil2206 · 2026-09-03T05:13:13Z

@4og sure I will clean up the nitpicking things mentioned altogether once we reached decision

github-project-automation Bot added this to BAS - Baselibs FT Aug 26, 2026

github-project-automation Bot moved this to In Progress in BAS - Baselibs FT Aug 26, 2026

Nikhil2206 requested a deployment to workflow-approval August 26, 2026 06:54 — with GitHub Actions Waiting

proposed 2 option to import libac

29046b4

Nikhil2206 force-pushed the libacl-import-options branch from f09b1c6 to 29046b4 Compare August 26, 2026 06:57

Nikhil2206 deployed to workflow-approval August 26, 2026 06:57 — with GitHub Actions Active

4og reviewed Aug 26, 2026

View reviewed changes

Nikhil2206 commented Aug 27, 2026

View reviewed changes

Nikhil2206 deployed to workflow-approval August 31, 2026 10:11 — with GitHub Actions Active

github-actions Bot added c++ C++ code bazel Bazel and Starlark build files labels Aug 31, 2026

Nikhil2206 force-pushed the libacl-import-options branch from aaf57cd to b5a4612 Compare September 1, 2026 08:00

Nikhil2206 deployed to workflow-approval September 1, 2026 08:00 — with GitHub Actions Active

Nikhil2206 force-pushed the libacl-import-options branch from b5a4612 to 492a72d Compare September 1, 2026 09:44

Nikhil2206 requested a deployment to workflow-approval September 1, 2026 09:45 — with GitHub Actions Waiting

github-actions Bot added the comp-osal Related to score/os component label Sep 1, 2026

Nikhil2206 force-pushed the libacl-import-options branch from 492a72d to 8ef98c5 Compare September 1, 2026 11:07

Nikhil2206 deployed to workflow-approval September 1, 2026 11:07 — with GitHub Actions Active

Nikhil2206 changed the title ~~proposed 2 option to import libac~~ libacl import options to address -fPIC link issue Sep 1, 2026

Nikhil2206 changed the title ~~libacl import options to address -fPIC link issue~~ libacl import options to address -fPIC and other similar issue Sep 1, 2026

4og requested changes Sep 2, 2026

View reviewed changes

Supporting libacl by building from source

547cc81

Nikhil2206 force-pushed the libacl-import-options branch from 8ef98c5 to 547cc81 Compare September 7, 2026 05:31

Nikhil2206 deployed to workflow-approval September 7, 2026 05:32 — with GitHub Actions Active

Nikhil2206 closed this Sep 15, 2026

github-project-automation Bot moved this from In Progress to Done in BAS - Baselibs FT Sep 15, 2026

Nikhil2206 reopened this Sep 17, 2026

Nikhil2206 requested a deployment to workflow-approval September 17, 2026 08:28 — with GitHub Actions Waiting

Conversation

Nikhil2206 commented Aug 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Replace prebuilt acl .deb with a hermetic, source-built libacl

What's included

Validation

Uh oh!

github-actions Bot commented Aug 26, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

4og Aug 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Nikhil2206 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Nikhil2206 commented Sep 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Nikhil2206 commented Aug 26, 2026 •

edited

Loading

Replace prebuilt acl `.deb` with a hermetic, source-built `libacl`

4og Aug 26, 2026 •

edited

Loading

Nikhil2206 left a comment •

edited

Loading