Ubuntu Python 3.6 error

[fredrikaverpil]

I had issues building PySide2 with Python 3.6 on Ubuntu 14.04/Trusty and 16.04/Xenial. Not sure why. I'm tracking this in a separate branch. Any help here is appreciated.

[leycec]

That's... not good. Would you mind posting a link to a sample build log?

[fredrikaverpil]

Sure, here's the Travis build with failing 3.6 builds: https://travis-ci.org/fredrikaverpil/pyside2-wheels/builds/267063400?utm_source=github_status&utm_medium=notification

[leycec]

I see, yet I don't see. shiboken2 linkage failed for inexplicable reasons, suggesting a Python 3.6-specific upstream issue. The pertinent log lines appear to be:

[ 26%] Linking CXX shared library libshiboken2.cpython-36m-x86_64-linux-gnu.so
/usr/bin/ld: /usr/local/lib/libpython3.6m.a(abstract.o): relocation R_X86_64_32S against `_Py_NotImplementedStruct' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libpython3.6m.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status 

Ugh. This is outside of our court, I'm afraid. The error suggests that shiboken2 is not being linked under the -fPIC option. If so, that's terrible. Position-independent code (PIC) is usually a firm requirement when building a shared library – in this case, shiboken2.so.

Would you mind forwarding a raw build log to upstream? ^{I know, I know. Time.}

Unrelatedly, have you seen PYSIDE-560? It states:

Since Python 3.2, there exists a stable ABI that allows linking against Python3 instead of enumerating each single version. This is achieved by certain restrictions. Try to achieve this for PySide. Goal: Build wheels for Python 3.4, 3.5, 3.6 etc.

Now, that is interesting.

[fredrikaverpil]

But how is this possible... I was able to build with Python 3.6 on CentOS, Windows and macOS without issues.

[leycec]

I see even deeper. This StackOverflow answer to a question exhibiting the same linker error suggests that Python 3.6 needs to be built with the --enable-shared option, which it is under Ubuntu but often is not under continuous integration (e.g., Travis-CI, Circle-CI).

I'm unclear whether Travis-CI manages Python versions with the pyenv utility or not. If it does, the solution appears to be:

PYTHON_CONFIGURE_OPTS="--enable-shared" pyenv install --force 3.6.2

This appears to be our problem, sadly. More investigation is required, but I'm about to collapse into my own late-night pudding. I leave this in your capable hands, good Sir!

[fredrikaverpil]

I'm building Python 3.6 from source. But I actually did try --enable-shared first. That also failed. I can commit this now, and you can see the output.

[leycec]

That also failed.

Err... really? With a different but equally fatal compilation or linker error, hopefully? Christ-on-a-stick.

[fredrikaverpil]

I actually first didn't build Python 3.6 at all. I just used a PPA, but this also failed. I don't recall the exact error... but I think it was the very same one.

Here's the new commit building: https://travis-ci.org/fredrikaverpil/pyside2-wheels/builds/267086001?utm_source=github_status&utm_medium=notification

[leycec]

I just used a PPA...

Maybe the PPA failed to build Python 3.6 with --enable-shared, because it's a bad PPA? This is fascinating, but I must fall asleep on my crusty bed now. Let us reconvene when I am not walking dead.

[fredrikaverpil]

Yes. And I must work. Talk later.