Ned Deily added the comment: Thanks for the report. It seems to me this is a very rare case here: since libz is supplied by OS X, it would be untypical for someone building Python to supply their own version in $HOME/lib. But, further, the point of the test is not to find the copy of libz that Python was built with, rather it is just to verify that the darwin version of ctypes.find_library() can find system libraries at their well-known locations. It would be somewhat difficult to set up a test of all of the search paths that are used, emulating the behavior of the system dynamic loader, dyld. As documented in the code and in the man page for dyld, the relevant search path is DYLD_FALLBACK_LIBRARY_PATH, which is $(HOME)/lib:/usr/local/lib:/lib:/usr/lib. So the test will unexpectedly find libz in $HOME/lib first, as it did for you.
I was going to assert that you were the first person to ever report running into this issue but, searching a bit, I found Issue1544102 which was never resolved but, thanks to your analysis, I now suspect was another instance with the same root cause. I guess we could change the test to accept a libz found in $HOME/lib or /usr/local/lib as well. Or we could just search for a different versioned system library less likely to shadowed in those locations, e.g. one not used in a Python build. ---------- nosy: +ned.deily, ronaldoussoren priority: normal -> low stage: -> needs patch type: compile error -> versions: +Python 3.5 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21093> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
