New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Building sharedmods fails with any dangling symlink in include path #101778
Comments
I tried reproducing this on my Linux machine but wasn't able to 😕 |
@FFY00 Thanks for trying. Can you share what the exact test you tried was? |
@jmroot sorry for the delay. I don't remember now, but if you can give me reproduction instructions, I can try on a macOS 13.3 machine. |
@FFY00 If you have MacPorts installed, this will do it:
I haven't tried a manual build, but can if you need me to. It's possible that implicit include dirs like |
To reproduce this:
The problem is that diff --git a/setup.py b/setup.py
index 4f122b62e0..ad8fb81b21 100644
--- a/setup.py
+++ b/setup.py
@@ -224,6 +224,7 @@ def is_macosx_sdk_path(path):
def grep_headers_for(function, headers):
for header in headers:
+ if not os.path.exists(header): continue
with open(header, 'r', errors='surrogateescape') as f:
if function in f.read():
return True I haven't checked yet if a fix is needed on main an 3.12, where |
…he directory containing "ffi.h"
Thanks for tracking this down @ronaldoussoren! Confirming that your patch fixes the issue for me. |
Thanks for the confirmation. |
Bug report
I am the maintainer of the Python ports in MacPorts. Ports generally install their headers to
/opt/local/include
, and that is the case for several of Python's dependencies, so we configure the Python build to use it. It appears that Python will fail to build if any dangling symlink exists in that include directory, even if it's not a header that Python uses at all. The build output ends like this:There is no reference to
lapacke_utils.h
anywhere in the configured sources, so I can only assume something must be scanning the entire include path. Of course our OpenBLAS port should not be installing dangling symlinks, but I think the Python build system should be able to tolerate them when they are not something that is needed or used at all.I think this was the first downstream report of this issue, and has a full log attached: https://trac.macports.org/ticket/66242
Your environment
Linked PRs
The text was updated successfully, but these errors were encountered: