[issue40900] uuid module build fix on FreeBSD proposal

[Kubilay Kocak]

Kubilay Kocak <koobs.freebsd at 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 <report at bugs.python.org>
<https://bugs.python.org/issue40900>
_______________________________________