On Mon, May 20, 2019 at 8:09 AM Miro Hrončok <mhroncok@redhat.com> wrote:
On 20. 05. 19 14:58, Richard Shaw wrote:
> I'm trying to get FreeCAD back in shape on Fedora[1] and what I hope is the last
> problem is that it's still building against the Python2 library (because it's
> default). I can override the behavior by specifying "-DPYTHON_SUFFIX=<python3
> SOABI> but it's different for every arch...
>
> $ python3
> Python 3.7.3 (default, Mar 27 2019, 13:41:07)
> [GCC 8.3.1 20190223 (Red Hat 8.3.1-2)] on linux
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import sysconfig
>  >>> sysconfig.get_config_var('SOABI')
> 'cpython-37m-x86_64-linux-gnu'
>
> I cobbled this together for the spec file but it may need work:
>
> %define py_suffix %(%{__python3} -c 'import sysconfig;
> sysconfig.get_config_var("SOABI")')

Or:

$ python3-config --extension-suffix
.cpython-37m-x86_64-linux-gnu.so

Potentially a little easier but then I would have to sed out the ".so"...


> The weird part is that it's evaluating as blank on Fedora 29 and 30[2] and
> working in Rawhide EXCEPT for armv7hl in which it's evaluating to[3]:
>
> -DPYTHON_SUFFIX=.cpython-37m-armv7hl-linux-gnu
>
> But the shiboken config file is named:
>
> /usr/lib/cmake/Shiboken-1.2.4/ShibokenConfig.cpython-37m-arm-linux-gnueabi.cmake
>
> Which is very different...
We do actually change some arch naming in here:

https://github.com/fedora-python/cpython/commit/e9def22e31801d9d75017e6752d3daf4099bc836

But not arm -> armv7hl.

I suspect that the name might be platform specific and the upstream name might
simply not be compatible with what we have in Fedora.

Ok, is this a recent change that a simple rebuild would fix? Shouldn't the shiboken cmake file be generated using the same logic? 

Thanks,
Richard