Ned Deily <n...@python.org> added the comment:

It seems to me that some (most?) of the macOS-specific workarounds in setup.py 
were added to make it easy to build with the system-provided copies of the 
third-party libraries, like zlib and sqlite3 and openssl. At least one of the 
workarounds, search_paths_first, became the default ld behavior since around 
macOS 10.6 (Xcode 4). So when building on more recent macOS systems, either the 
workarounds aren't necessary any more or the third-party library is no longer 
provided (like openssl) or is otherwise too old (like Tk) so that you can no 
longer rely on building with just using system-supplied libraries to have a 
useful Python on macOS. And, if you are building on very old systems (because 
of hardware requirements or whatever), in most cases, the versions of the 
system-supplied libraries are so old that you shouldn't be relying on them 
anyway. So I think that, for 3.11, we could take a stand and say that we no 
longer support building with specific system-supplied third-party libraries
  on macOS systems older than, say, macOS 10.9; IOW, you will need to supply 
your own copies of those libs on older systems. That's essentially the approach 
the MacPorts project has taken for years; they still support providing current 
Pythons on old versions of macOS but they also supply current version of the 
third-party libs, too.

And Christian's work here for 3.11 to move away from setup.py and use 
pkg-config to remove the guesswork on header and lib locations should make life 
easier for everyone. There is a small issue here in that macOS does not supply 
a built-in pkg-config but there are implementations available, if you are 
unable or unwilling to use open source distributors like MacPorts or Homebrew, 
including an actively-maintained permissive-licensed version with no build 
dependencies that seems to work on even macOS 10.6 (I didn't try anything older 
than that!): https://github.com/pkgconf/pkgconf.

Ronald, what do you think?  If this sounds reasonable, we could draw up a list 
of libs and document it somewhere in the 3.11 code.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue45743>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to