This issue was resolved by incorporating the gem5 library into the binary: https://gem5-review.googlesource.com/c/public/gem5/+/49690

the only reason for distributing the libraries separately (in any form, via pip being one such option) is if someone seriously is considering using them separately from the binaries and without the binaries. given the integrated and specialist nature of gem5 this strikes me as quite unlikely.

with pip’s security being utterly brain-dead (non-existent i.e. critically reliant on a server not getting hacked) the thought of gem5 itself being made to depend on that should fill you with alarm. in addition, version management then becomes a serious headache: be prepared even amongst experienced developers for “i have version conflict between library date X and binary date Y”

the only reason to consider where the libraries are installed - i assume we are talking c-based python modules here - is if there are a shed-load being dropped into /usr/local/lib and it’s getting unwieldy. in which case being able to specify a path and that path is auto-managed by the OS, then pkg-config is your friend. there’s also a python package to access and manage pkg-config. autoconf creates them as a no-brainer, gem5 uses scons, and there shouuuld be… ah, yes:

https://github.com/manuelnaranjo/scons-pkg-config/blob/master/__init__.py

if scons doesn’t read pkg-config by default that shows how to do it.