Libs within a wheel have wrong RUNPATHs

[KOLANICH]

To Reproduce
Steps to reproduce the behavior, e.g.:

1. python3 -m build -nwx .
2. extract the wheel into a dir
3. readelf -d ./symforce-0.8.0-cp311-cp311-linux_x86_64/cc_sym.cpython-311-x86_64-linux-gnu.so
4. see 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../..:./build/temp.linux-x86_64-cpython-311] (the path is edited, full path to the cloned repo was replaced by ./)

Expected behavior
No global paths should be leaked into binaries.

Environment (please complete the following information):

• OS and version: Debian sid
• Python version 3.11
• SymForce Version c3d2f3c

[aaron-skydio]

Just a note that I believe this is what's handled by auditwheel / delocate in the standard pipeline of building wheels for distrubution (including in our GitHub Actions pipeline for building wheels).

As for what we want python -m build to do by default, I'm not sure, and I might have to look around a bit more. I believe installing a wheel with these local runpaths should and does work on the machine that built the wheel, and the correct way to handle this for distribution is with the above tools (for distribution as wheels on PyPI, not making any claims on distribution through system package managers, which we don't currently do). There's a secondary question of whether we should structure our compiled libraries differently, e.g. statically linking libsymforce* into cc_sym.so, but I think that's a question for #334?

[KOLANICH]

Thanks for the info! Just to note: all the Python packages using cexts I have encountered before didn't need the processing with the mentioned tools, so I was surprized.

There's a secondary question of whether we should structure our compiled libraries differently, e.g. statically linking libsymforce* into cc_sym.so, but I think that's a question for #334?

Yeah.