Kubilay Kocak <koobs.free...@gmail.com> added the comment:
FreeBSD base provides uuid.h (uuid(3)) but uuid libraries/headers can be provided by e2fsprogs-libuuid (for example) in another location, for example /usr/local/ Pythons build system doesn't provide sufficient granularity to pass include/library locations for *specific* components of the build in every circumstance. The following is a bug related to Python 3.7+ and the uuid.h / linking problem: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229562 The current patch just ignores the third-party (/usr/local) version of uuid.h, allowing the build to proceed with the headers provided by base: https://bz-attachments.freebsd.org/attachment.cgi?id=200603 The proper/permanent solution might be to allow a --with-uuid=<location> style build argument This issue of conflicting / multiple library versions and include order has also come up in various forms for other third party library support in Python, such as gettext (libintl), expat, ssl, libffi, curses) See the following FreeBSD Python port block for the libintl example: https://svnweb.freebsd.org/ports/head/lang/python37/Makefile?revision=536776&view=markup#l71 ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue40900> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
