[ovs-dev] [PATCH] Revert "Test the Python C JSON extension"

[Lam, Tiago]

On 15/10/2018 17:44, Ilya Maximets wrote:
> This reverts commit a7be68a4d77791bbe02c37f7ad8ae60b02e5679e
> and a subsequent commit 4617d1f6bd24c543f533f6485b42ebca6b0a8371.
> There are too many issues with these patches. It's better to revert
> them for now and make a separate fixed versions later if needed.
> 
> List of issues (maybe not full):
> 
> 1. 'make clean' removes entire 'python' directory.
> 
> 2. Fully broken Travis-CI testsuite build:
>     building 'ovs._json' extension
>     creating build/temp.linux-x86_64-2.7
>     error: could not create 'build/temp.linux-x86_64-2.7': \
>            Permission denied
>     https://travis-ci.org/openvswitch/ovs/jobs/440693765
> 
> 3. Broken local testsuite build on Ubuntu 18.04:
>     running build_ext
>     building 'ovs._json' extension
>     creating build/temp.linux-x86_64-3.6
>     creating build/temp.linux-x86_64-3.6/ovs
>     <...>
>     /usr/bin/ld: .libs/libopenvswitch.a(util.o): \
>         relocation R_X86_64_TPOFF32 against `var.7749' can not be \
>         used when making a shared object; recompile with -fPIC
>     <...>
>     collect2: error: ld returned 1 exit status
> 
> 4. Fedora build failure because of 'setuptools' ('distutils')
>    hard dependency on 'redhat-rpm-config' package:
>     building 'ovs._json' extension
>     <...>
>     gcc: error: <...>/redhat-hardened-cc1: No such file or directory
> 
> 5. Looks like 'setuptools' also could download and install
>    unwanted python modules during package build.
> 
> Signed-off-by: Ilya Maximets <i.maximets at samsung.com>
> ---

(I'm CC'ing the author of the patch since I don't see him in the address
list for this patch).

Thanks, Ilya. I hadn't seen this patch before submitting mine.

The problem I was seeing with 3. is that beginning with commit a7be68a
the build now tries to build the Python JSON C extension by default
(shared), and tries to link to libopenvswitch, which most likely hasn't
been built with a "-fPIC" flag, producing several `ld` errors and "***"
warnings. So, instead of trying to build the C extension and using the
Python lib as an alternative if the former fails, which ends up
polluting the build system, I think we could try to detect which JSON
extension to use before proceeding. Perhaps detecting for
"--enable-shared" could be sufficient here, and only try to build the
extension if one builds a shared version of libopenvswitch.

But I agree that this needs to be rethought.

Tiago.