Musl build fails due to a a missing _SC_LEVEL1_DCACHE_LINESIZE.

[expenses]

Description of Issue

I recently tried to get OpenUSD building for the Musl libc so that I could have a totally static build. To do this I'm using the nix flake I wrote for openusd: https://github.com/expenses/openusd-minimal-nix, using the musl callPackage: musl = pkgs.pkgsMusl.callPackage ./package.nix { };. Compiliation fails with the following:

/build/source/pxr/base/arch/assumptions.cpp:54:20: error: ‘_SC_LEVEL1_DCACHE_LINESIZE’ was not declared in this scope
make[2]: *** [pxr/base/arch/CMakeFiles/arch.dir/build.make:236: pxr/base/arch/CMakeFiles/arch.dir/assumptions.cpp.o] Error 1

This appears to be a fairly well-known issue, taviso/ctypes.sh#53 is the same thing.

Package Versions

I'm attempting to build v23.11 (commit 0b18ad3) on x86_64 linux, everything else is kinda N/A at this time.

The commit of the flake I'm testing is expenses/openusd-minimal-nix@825a126 with a small patch:

diff --git a/flake.nix b/flake.nix
index 1dcdf7a..2c4b6e0 100644
--- a/flake.nix
+++ b/flake.nix
@@ -22,6 +22,8 @@
             static = true;
           };

+          musl = pkgs.pkgsMusl.callPackage ./package.nix { };
+
           windows = pkgs.pkgsCross.mingwW64.callPackage ./package.nix { };
         };
       };

I'm going to try and patch around this issue to see if I can get this working.

[meshula]

Support for MUSL would be nice, because it opens the door to interoperability with several systems that pose challenges today (an example being the zig compilation environment). I am wondering if there are one or two things that would need to be tidied up in pxr/base/arch? Or is it a bottomless pit of "oh no, what now???"

[expenses]

@meshula I just applied a bunch of hacky patches and got it compiling with just this: release...expenses:USD:musl-patch. Looks like it's mostly contained to pxr/base/arch with a few missing file defines.

[meshula]

Looks straight forward, and could probably resolved fairly transparently. The nice to have would be a solution for return 0;//sysconf(_SC_LEVEL1_DCACHE_LINESIZE); ~ I realize you mentioned it's hacky, but a principled fix doesn't seem that far off :)

[jesschimein]

Filed as internal issue #USD-9276

[expenses]

Looks straight forward, and could probably resolved fairly transparently. The nice to have would be a solution for return 0;//sysconf(_SC_LEVEL1_DCACHE_LINESIZE); ~ I realize you mentioned it's hacky, but a principled fix doesn't seem that far off :)

Yep, I totally agree. I was just investigating what was required to get things building in a reasonably correct manner.

[romainf-ubi]

I'm having an issue because of Musl too. In our CI/CDs, we're using an image based on Alpine. It's not easy to change the base image as it's the same image for all our .NET projects. We didn't have issues until this one .NET project requiring to run a Python script depending on the usd-core module.

We could try and change for a stable-slim Debian, but I must admit that having usd-core compatible with Musl, and thus, Alpine, would help us a lot 😉

(Just for cross-referencing, it's also mentioned in this other comment: #1073 (comment))