sysroot: fix missing symlinks for blas and lapack [IO-60] #25
+24
−40
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
To support cross-compiling from x86_64 to aarch64 debian targets - we're using some scripts from the chromium
project for building sysroots directly from debian (
.deb
) packages.A caveat of using these scripts is they rely on very low level plumbing commands (i.e.
dpkg-deb
) to handle unpackingand installing the package contents (libs and headers), into "jail" (the sysroot).
These commands don't handle many details of the full install process. In the case of blas and lapack - they don't handle the post install step of creating symlinks at
/usr/lib/${TRIPLE}/libblas.so
. This is important because this location is on the linkers default search path. The reason these symlinks are not part of the package by default is because blas and lapack are virtual packages, there are several different "concrete" packages that can satisfy the dependency (i.e.libblas-dev
,libopenblas-dev
, etc..). It's up the the debian alternatives system (& system administrators) to handle the detail of which concrete library thelibblas
andliblapack
symlinks actually point to.I explored a couple of routes to try to do this in a less janky way then manually creating the links, but this ended up being a rabbit hole. Ideally we revisit the way we're building these sysroots in a more robust way.
In the meantime we can now remove the hardcoded linker paths in libraries that depend on
blas
andlapack
:https://github.com/swift-nav/rules_swiftnav/blob/d10814e9b8f3d3b948e3ea9c1aed9c80c2fd74cc/third_party/suitesparse.BUILD#L25. Trying to handle all the different conditions (os, arch, sysroot or no sysroot, etc..) was becoming untenable, and just didn't work at all in some cases.
Testing
I've tested the resulting sysroot build locally to verify that this mechanism of creating the links works.