This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author koobs
Recipients christian.heimes, devnexen, koobs
Date 2020-06-08.03:21:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1591586506.83.0.716936042668.issue40900@roundup.psfhosted.org>
In-reply-to
Content
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
History
Date User Action Args
2020-06-08 03:21:46koobssetrecipients: + koobs, christian.heimes, devnexen
2020-06-08 03:21:46koobssetmessageid: <1591586506.83.0.716936042668.issue40900@roundup.psfhosted.org>
2020-06-08 03:21:46koobslinkissue40900 messages
2020-06-08 03:21:46koobscreate