[issue40900] uuid module build fix on FreeBSD proposal

[Danilo G. Baio]

Change by Danilo G. Baio :


--
nosy: +dbaio

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40900] uuid module build fix on FreeBSD proposal

[Tiago Illipronti Girardi]

Tiago Illipronti Girardi  added the comment:

The problem isn't exclusive to FreeBSD. There are at least 3 problems here (see 
also: issue 32627).

-First is that there are 2 low-level uuid interfaces (3 if you count Windows 
but that is isolated and not a problem here) supposed to be declared on the 
headers below:

1) uuid/uuid.h which is supposed to maybe declare
uuid_generate_time_safe and declare uuid_generate_time, and probably must be 
linked with '-luuid'.

2) uuid.h: which is supposed to declare uuid_create and maybe uuid_enc_be 
(which as I understand is libc on FreeBSD an some others).

The way it currently works (I guess, 'configure' conspicuously doesn't end in 
'.py'), 'configure' tries to find uuid/uuid.h, if it succeeds, it `#define 
HAVE_UUID_UUID_H 1`, then it tries to find 'uuid.h', which on success `#define 
HAVE_UUID_H 1`.

Then it tries to compile with `#include ` and getting the address 
of `uuid_generate_time_safe`. On success, `#define HAVE_UUID_GENERATE_TIME_SAFE 
1.`

Next, `#include ` and first tries to compile a code that gets 
`uuid_create`'s adress (on success `#define HAVE_UUID_CREATE 1`), then compile 
to get `uuid_enc_be` adress (on success `#define HAVE_UUID_ENC_BE 1`).

The last two ignores header detection information.

-The second problem is on `make build` and 'setup.py':

Then 'setup.py' proceeds to ignore all that and tries to find 'uuid.h' on 
`Py_build_ext(dist).inc_dirs` or in '/usr/include/uuid', which doesn't work if 
the user has 'uuid/uuid.h' in `inc_dirs` but not in '/usr/include/uuid'. (It 
should get the macros from sysconfig and see which header it is looking for and 
not put '/usr/include/uuid' on the search path, 'configure' already found or 
not and already disabled the include if not.)

If it finds it, it tries to find the uuid library, and adds it to linking on 
success, else assumes it doesn't need to do anything else and succeeds.

If it doesn't find the header (which it may not, even if 'configure' did it), 
it gives up on the module and warns the user in the end of `make build`.

-Third, Modules/_uuidmodule.c (see issue 32627):

Inspect the `#includes` and `py_uuid_generate_time_safe()` and you can probably 
guess how this happens, and you can probably see another bug waiting to to 
happen: neither 'configure', nor 'setup.py' actually do what '_uuidmodule.c' is 
expecting, and `py_uuid_generate_time_safe()` will fallback to 
`uuid_generate_time()` which may not be declared (which gives you another bug, 
but on linking time, because you may not have passed '-luuid').

At least on Linux (CentOS) on a custom --prefix, with custom libuuid.so, this 
proccess fails on Python 3.8.3. I edited 'setup.py' to correctly find the 
header and the library (for my case, anyway, I have no idea on FreeBSD) and it 
worked. (You don't support this use case, but that's another issue, just adding 
more info.)

OP's patch (which appears to be to check the functions only on detection of the 
respective modules) may work for his specific case, but I suspect that for a 
more stable solution we need to change _uuidmodule.c and at least one of 
'configure(.ac)' and 'setup.py':
 - the module directives should behave as 'configure' tests;
 - which should ideally test for `uuid_generate_time()`;
 -'setup.py' should listen to 'configure' the same way the module directives do.

(and by 'we' I mean I'm volunteering to help, but I will need help on that).

Maybe what I'm saying should be another issue entirely, though I'm adding build 
to components (and I think we should include 3.8 and 3.9 too). Please advise.

--
components: +Build
nosy: +TIGirardi

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40900] uuid module build fix on FreeBSD proposal

[Kubilay Kocak]

Kubilay Kocak  added the comment:

Another example, this time for lzma:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209355

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40900] uuid module build fix on FreeBSD proposal

[Kubilay Kocak]

Kubilay Kocak  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= 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=markup#l71

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40900] uuid module build fix on FreeBSD proposal

[David CARLIER]

David CARLIER  added the comment:

This s about header picked up in a certain order. In case of FreeBSD, the 
uui_create case is taken which comes from the  but ...  is 
detected too.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40900] uuid module build fix on FreeBSD proposal

[Christian Heimes]

New submission from Christian Heimes :

Please explain which problem you are facing and how your proposal is going to 
fix the problem.

--
nosy: +christian.heimes

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40900] uuid module build fix on FreeBSD proposal

[David CARLIER]

Change by David CARLIER :


--
components: FreeBSD
nosy: devnexen, koobs
priority: normal
pull_requests: 19908
severity: normal
status: open
title: uuid module build fix on FreeBSD proposal
type: compile error
versions: Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com