package/python3: require util-linux' <uuid.h>

Without this dependency, a top level parallel build fails for me (-j24):

  /home/ci/build/build/host-python3-3.7.2/Modules/_uuidmodule.c: In function 'py_uuid_generate_time_safe':
  /home/ci/build/build/host-python3-3.7.2/Modules/_uuidmodule.c:15:5: error: unknown type name 'uuid_t'; did you mean 'uid_t'?
       uuid_t uuid;
       ^~~~~~
       uid_t
  /home/ci/build/build/host-python3-3.7.2/Modules/_uuidmodule.c:32:5: error: implicit declaration of function 'uuid_generate_time'; did you mean 'py_uuid_generate_time_safe'? [-Werror=implicit-function-declaration]
       uuid_generate_time(uuid);
       ^~~~~~~~~~~~~~~~~~
       py_uuid_generate_time_safe

I *suspect* that this is due to host-uboot-tools which provide
/usr/include/uuid.h and which gets accidentally picked by python3.

There's a bugreport [1] upstream which at leeast appears to be relevant.

[1] https://bugs.python.org/issue32627

Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz>
---
 package/python3/python3.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Hello Jan,

On Thu, 7 Mar 2019 17:23:36 +0100
Jan Kundrát <jan.kundrat@cesnet.cz> wrote:

> Without this dependency, a top level parallel build fails for me (-j24):

Is this with the per-package directory patch set applied, or top-level
parallel build with the Buildroot master (which is a totally
unsupported configuration) ?

> I *suspect* that this is due to host-uboot-tools which provide
> /usr/include/uuid.h and which gets accidentally picked by python3.

I think we need a better understanding of why this would be needed.
host-python3 builds just fine in minimal chroot that does not have
libuuid-dev installed, otherwise the autobuilders would be full of
host-python3 build failures.

So we need more research and a more convincing explanation.

Thanks!

Thomas

On 07/03/2019 17:23, Jan Kundrát wrote:
> Without this dependency, a top level parallel build fails for me (-j24):
> 
>   /home/ci/build/build/host-python3-3.7.2/Modules/_uuidmodule.c: In function 'py_uuid_generate_time_safe':
>   /home/ci/build/build/host-python3-3.7.2/Modules/_uuidmodule.c:15:5: error: unknown type name 'uuid_t'; did you mean 'uid_t'?
>        uuid_t uuid;
>        ^~~~~~
>        uid_t
>   /home/ci/build/build/host-python3-3.7.2/Modules/_uuidmodule.c:32:5: error: implicit declaration of function 'uuid_generate_time'; did you mean 'py_uuid_generate_time_safe'? [-Werror=implicit-function-declaration]
>        uuid_generate_time(uuid);
>        ^~~~~~~~~~~~~~~~~~
>        py_uuid_generate_time_safe
> 
> I *suspect* that this is due to host-uboot-tools which provide
> /usr/include/uuid.h and which gets accidentally picked by python3.

 I don't see host-uboot-tools install uui.h in $(HOST_DIR)/include... ARe you
sure that is where it comes from? Is that what packages-file-list-host.txt says?

 Anyway, nothing should install anything in /usr/include. Maybe that's the
problem, that you have a wrong /usr/include/uuid.h installed on your system?

 Regards,
 Arnout

> 
> There's a bugreport [1] upstream which at leeast appears to be relevant.
> 
> [1] https://bugs.python.org/issue32627
> 
> Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz>
> ---
>  package/python3/python3.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/package/python3/python3.mk b/package/python3/python3.mk
> index ef2c4857d8..dcec210674 100644
> --- a/package/python3/python3.mk
> +++ b/package/python3/python3.mk
> @@ -40,7 +40,7 @@ HOST_PYTHON3_CONF_ENV += \
>  
>  PYTHON3_DEPENDENCIES = host-python3 libffi
>  
> -HOST_PYTHON3_DEPENDENCIES = host-expat host-zlib host-libffi
> +HOST_PYTHON3_DEPENDENCIES = host-expat host-zlib host-libffi host-util-linux
>  
>  PYTHON3_INSTALL_STAGING = YES
>  
>

> Is this with the per-package directory patch set applied, or top-level
> parallel build with the Buildroot master (which is a totally
> unsupported configuration) ?

It was with the totally unsupported top-level parallel build with Buildroot 
master. I thought that it was just a mere issue with dependencies, but 
apparently it's a fragile upstream. I can confirm that the per-package 
directory patch makes it stable.

As such, I think that there's little point in fixing this within buildroot. 
I'm looking forward towards a merge of the per-package build dir. Sorry for 
noise!

With kind regards,
Jan

Hello Jan,

On Tue, 12 Mar 2019 16:26:07 +0100
Jan Kundrát <jan.kundrat@cesnet.cz> wrote:

> It was with the totally unsupported top-level parallel build with Buildroot 
> master. I thought that it was just a mere issue with dependencies, but 
> apparently it's a fragile upstream. I can confirm that the per-package 
> directory patch makes it stable.
> 
> As such, I think that there's little point in fixing this within buildroot. 
> I'm looking forward towards a merge of the per-package build dir. Sorry for 
> noise!

Top-level parallel build without per-package build directories is still
never going to work reliably, which is why top-level parallel build is
forcefully disabled in the main Buildroot Makefile today. We are not
going to merge fixes or quirks for top-level parallel build without
per-package directories.

Thanks for confirming!

Best regards,

Thomas