libselinux: fix build on 32-bit LFS platforms

[mildsunrise]

Compilation of libselinux on modern 32-bit platforms has been broken since v3.8. For example:

nix-build --arg crossSystem '{ config="riscv32-unknown-linux-gnu"; }' -A libselinux

A debian maintainer and me prepared a fix in SELinuxProject/selinux#464 (see discussion and first commit), and I'd like to get this patch here while it's reviewed and released upstream (hopefully in some months). The patch is small and I've tested it doesn't break the build on x64 (a 64-bit platform) and x86 (a 32-bit non-LFS platform).

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
• N/A Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • N/A (Package updates) Added a release notes entry if the change is major or breaking
  • N/A (Module updates) Added a release notes entry if the change is significant
  • N/A (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[mildsunrise]

I've also checked we still get the two symbols in x86

# nm -D /nix/store/4agsd6q8snyzihf1zkn3n7izdmxafycb-libselinux-i686-unknown-linux-gnu-3.8/lib/libselinux.so | grep add
         U ___tls_get_addr@GLIBC_2.3
000091cd T avc_add_callback@@LIBSELINUX_1.0
0001b358 T matchpathcon_filespec_add@@LIBSELINUX_1.0
0001b0fb T matchpathcon_filespec_add64@@LIBSELINUX_3.8
         U readdir64@GLIBC_2.2
0001eadd T selinux_failsafe_context_path@@LIBSELINUX_1.0

as expected this causes a mass rebuild so I'll target staging

[RossComputerGuy]

Looks good now, I'll hold off on merging until the upstream PR is closer to being merged in case anything changes.

[numinit]

Patch looks fine to me.

[mildsunrise]

upstream has (to the best of my knowledge) remained silent on this issue for almost 2 months now.
can we fix the build now, and if/once they fix this upstream, update the patch?

[numinit]

That sounds fine to me.

[mildsunrise]

thanks!!

[alyssais]

Broke musl :(

[mildsunrise]

huh, i am surprised that this even compiled with musl to begin with, I thought __ino_t was a glibc nonportable type... let me see

[alyssais]

Already submitted a patch upstream :)

[alyssais]

Please test: #402027

[mildsunrise]

thanks for fixing! I think you forgot to add the defined(__INO64_T_TYPE) guard to the header too? (look at the previous hunk in the patch). otherwise it looks correct to me... I'm not sure what's the best way to detect whether the libc participates in the 2038y proofness design or not, but since glibc is the only participant I'm aware of, I guess __INO64_T_TYPE is just as good as any other glibc internal define.

okay it isn't 100% correct, as it would IIUC still fail when building with USE_LFS=n (which would be weird to touch when building with musl anyway, but it might still trip some folks).

but I'm still confused... the code was using __ino_t even before my patch, so it couldn't possibly build outside of glibc, at the very least for 32-bit platforms? am I missing something here? do we only test/care about musl builds with 64-bit platforms?

[alyssais]

'm not sure what's the best way to detect whether the libc participates in the 2038y proofness design or not, but since glibc is the only participant I'm aware of

It's not that other libcs aren't 2038-proof, it's that only Glibc lets you mix 2038-proof and non-2038-proof types. musl only provides 64-bit types.

do we only test/care about musl builds with 64-bit platforms?

I certainly don't care about 32-bit platforms, and I've never come across anybody else who does for musl in Nixpkgs either, so I think it's just that nobody noticed.

[alyssais]

I think you forgot to add the defined(__INO64_T_TYPE) guard to the header too? (look at the previous hunk in the patch). otherwise it looks correct to me

I guess I did — surprising to me that it built…

[mildsunrise]

It's not that other libcs aren't 2038-proof, it's that only Glibc lets you mix 2038-proof and non-2038-proof types. musl only provides 64-bit types.

I know, y2038 proofness design refers to the whole _TIME_BITS macro system. AFAIK glibc is the only libc that follows this design, the rest fixed the problem by breaking ABI and making ino_t unconditionally 64-bit

I guess I did — surprising to me that it built…

yeah, it does build, just with the symbol renamed to [...]add64 since the define affects both prototype and definition in the .c

I certainly don't care about 32-bit platforms, and I've never come across anybody else who does for musl in Nixpkgs either, so I think it's just that nobody noticed.

ah okay, that expains it then :)