| 4 Jul 2026 |
 K900 | What encoding stuff | 14:14:48 |
 emily | the LDAC stuff | 14:15:10 |
| emily | some weird source dump thing we made opt-in | 14:15:16 |
| emily | # Upstream ships AOSP build files and a gcc/ makefile that only knows
# about the in-tree layout. Compile and link directly; the entire
# library is two umbrella translation units.
buildPhase = ''
runHook preBuild
soname=libldacBT.so.${lib.versions.major finalAttrs.version}
sofile=libldacBT.so.${finalAttrs.version}
$CC -shared -Wl,-soname,$soname src/ldaclib.c src/ldacBT.c abr/src/ldacBT_abr.c -lm -o $sofile
runHook postBuild
'';
| 14:15:38 |
| K900 | It's not licensing | 14:15:38 |
 Alyssa Ross | yeah can do | 14:15:42 |
| K900 | The build system is screwy | 14:15:43 |
| emily | so this PR obviously just broke the build completely on Darwin which doesn't use .so or -soname or any of that | 14:15:50 |
| K900 | But it's all apache2 in Sony or someone's AOSP drop | 14:15:53 |
| K900 | Why the fuck does anything use ldacbt on Darwin | 14:16:05 |
| emily | moving from CMake to a raw compiler invocation that also uses env.NIX_CFLAGS_COMPILE unnecessarily on top of that is not very funny | 14:16:22 |
| emily | GStreamer etc. | 14:16:27 |
| K900 | Oh god | 14:16:33 |
| K900 | Why does gstreamer | 14:16:38 |
| K900 | Ugh | 14:16:39 |
| emily | I'm a bit annoyed at this PR being merged | 14:17:11 |
| emily | like we went from a normal CMake build to manually calling the compiler and writing out a bunch of .pc files ourselves | 14:17:30 |
| K900 | Sorry I assumed it was only used by pipewire | 14:17:48 |
| K900 | Apparently not the case | 14:17:53 |
| emily | and I'm not seeing how this is meant to be an improvement except for the fact that it makes thing slightly nicer for LDAC encoding which AIUI is an extremely niche feature? | 14:17:58 |
| K900 | The cmake files are also not upstream fwiw | 14:18:36 |
| emily | also… | 14:18:38 |
| emily | https://github.com/open-vela
The openvela operating system is tailored for the AIoT field, with lightweight, standard compatibility, security and high scalability as its core features.
| 14:18:42 |
| emily | https://github.com/open-vela/external_libldac is this actually the AOSP upstream? | 14:18:49 |
| emily | or is this some IoT vendor fork of an AOSP repo that we're using for some reason now? | 14:18:58 |
| K900 | Like, the previous repo is just Some Guy taking Sony's AOSP source and duct taping cmake on top | 14:19:01 |
| emily | sure. this also seems pretty Some Guy though | 14:19:15 |
| K900 | AOSP libldac doesn't have a decoder | 14:19:16 |
| K900 | This is a maintained-ish fork of the original Sony drop | 14:19:31 |
| emily | ok | 14:19:59 |
