You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, if sysconfig's LDSHARED contains a -L flag, that flag will appear before user-provided flags when building an extension. If the user provides an additional path to search (e.g. via LDFLAGS), that path will have lower priority than paths in LDSHARED since library paths are searched left to right. This makes it hard for a user to prefer their own library, even when an undesired version is being found via LDSHARED.
Describe the solution you'd like
Ideally, there would be a way to search user-provided paths first. But I'm honestly not sure what this would look like, implementation-wise. Since LDSHARED contains both the linker invocation and flags to the linker, any solution would seem to need to parse LDSHARED to insert -L flags early. That seems fragile. However, there is precedent in the sense that LDSHARED is already automatically rewritten with a user-provided CC:
Users can currently pass LDSHARED to fully specify the linker command and the order of -L flags. This is currently the workaround I'm using. However, it's verbose (see below) and arguably error-prone, since it requires manually discovering the LDSHARED value and modifying it to insert your own paths first.
Additional context
Here's an example LDSHARED on my system, which contains a lot of paths a user might want to override (notably -L/usr/lib64):
What's the problem this feature will solve?
Currently, if sysconfig's
LDSHARED
contains a-L
flag, that flag will appear before user-provided flags when building an extension. If the user provides an additional path to search (e.g. viaLDFLAGS
), that path will have lower priority than paths inLDSHARED
since library paths are searched left to right. This makes it hard for a user to prefer their own library, even when an undesired version is being found viaLDSHARED
.Describe the solution you'd like
Ideally, there would be a way to search user-provided paths first. But I'm honestly not sure what this would look like, implementation-wise. Since
LDSHARED
contains both the linker invocation and flags to the linker, any solution would seem to need to parseLDSHARED
to insert-L
flags early. That seems fragile. However, there is precedent in the sense thatLDSHARED
is already automatically rewritten with a user-providedCC
:setuptools/setuptools/_distutils/sysconfig.py
Line 331 in ba24375
Alternative Solutions
Users can currently pass
LDSHARED
to fully specify the linker command and the order of-L
flags. This is currently the workaround I'm using. However, it's verbose (see below) and arguably error-prone, since it requires manually discovering theLDSHARED
value and modifying it to insert your own paths first.Additional context
Here's an example
LDSHARED
on my system, which contains a lot of paths a user might want to override (notably-L/usr/lib64
):Code of Conduct
The text was updated successfully, but these errors were encountered: