wxPython Phoenix build fail ("Could not build python extensions"?) in pyenv 3.5.1 on Linux

Michael_Freeman · July 12, 2019, 9:19pm

Hi,

I’m building wxPython for a Blender project here: https://blenderartists.org/forum/showthread.php?404099-DJ-turntable-platter-physics-simulation-Link-sound-pitch-to-platter-rotation-speed

I installed a full system Python 3.5.1 on my Windows machine to replace the one bundled with Blender. This works and installs the pre-built wxPython Phoenix OK. However I usually work on my Linux machine (if I can’t get this working there I will just have to use the Windows machine!).

Blender Python can be coaxed into using “pip” and so forth but its problematic. So I eventually got “pyenv” setup ( https://github.com/yyuu/pyenv ) …

> curl -L https://raw.githubusercontent.com/yyuu/pyenv-installer/master/bin/pyenv-installer | bash
> (add additions suggested by install script:) vim .bash_profile
> vim .bash_profile
> (show all commands:) pyenv
> (python version for Blender 2.77:) pyenv install 3.5.1
> (set globally:) pyenc global 3.5.1
> Remove or rename "python" directory in Blender folder.
> ln -s /home/michaelzfreeman/.pyenv/versions/3.5.1 python
> BLENDER NOW STARTS USING PYENV PYTHON
> pyenv rehash
> (Should show pyenv installed python version:) python

Blender loads up and OK and the game engine is fully functional importing various python modules.

I install wxPython Phoenix using:

pip install -v -U -f https://wxpython.org/Phoenix/snapshot-builds/ wxPython_Phoenix 2>&1 | tee pip_wxpython-phoenix_install_output.txt

which gives build errors: http://files.djbarney.org/pip_wxpython-phoenix_install_output.txt

(BTW same “pip” command with “–pre” downloads same archive).

I tried installing python module “pyext” but there’s no difference.

So I don’t understand what is going wrong here, any ideas ? The “pyenv” should provide everything and python3.5-dev & libpython3.5-dev are at latest version. Also …

$ pyenv which python-config --> /home/michaelzfreeman/.pyenv/versions/3.5.1/bin/python-config

Robin · July 12, 2019, 9:32pm

Michael Freeman wrote:

I install wxPython Phoenix using:

pip install -v
-U -f wxPython_Phoenix 2>&1 | tee pip_wxpython-phoenix_install_output.txtwhich gives build errors:

It looks like there are some prerequisites that don’t appear to be on your system. The wxWidgets build adapts okay to them not being present,
but Phoenix is still expecting them to be there and doesn’t yet know how to adapt if they are not. You’ll want to install development packages for the following, what the packages are actually named will depend on your linux distribution

python3.5-dev

libwebkitgtk-dev

libjpeg-dev

libtiff-dev

libgtk2.0-dev

libsdl1.2-dev

libgstreamer-plugins-base0.10-dev

libnotify-dev

freeglut3-dev

···

https://wxpython.org/Phoenix/snapshot-builds/

http://files.djbarney.org/pip_wxpython-phoenix_install_output.txt

Robin Dunn

Software Craftsman

http://wxPython.org

Michael_Freeman · July 12, 2019, 9:32pm

Thanks. I installed all those (already had some in there) but the build still fails. Is same log file link as I gave you before with updated file. Briefly looked through but shows the same errors as far as I can see.

···

On Wednesday, August 31, 2016 at 7:35:00 PM UTC+1, Robin Dunn wrote:

Michael Freeman wrote:

I install wxPython Phoenix using:

pip install -v
-U -f https://wxpython.org/Phoenix/snapshot-builds/ wxPython_Phoenix 2>&1 | tee pip_wxpython-phoenix_install_output.txt

which gives build errors: http://files.djbarney.org/pip_wxpython-phoenix_install_output.txt

It looks like there are some prerequisites that don’t appear to be on your system. The wxWidgets build adapts okay to them not being present,
but Phoenix is still expecting them to be there and doesn’t yet know how to adapt if they are not. You’ll want to install development packages for the following, what the packages are actually named will depend on your linux distribution

python3.5-dev

libwebkitgtk-dev

libjpeg-dev

libtiff-dev

libgtk2.0-dev

libsdl1.2-dev

libgstreamer-plugins-base0.10-dev

libnotify-dev

freeglut3-dev

–
Robin Dunn

Software Craftsman

http://wxPython.org

Michael_Freeman · July 12, 2019, 9:32pm

OK. I looked at this again.

First I don’t know how to confirm that my Linux (Ubuntu Xenial) Python
waf build system (in a “pyenv”) is actually fully functional. This should be done first as I’ve only ever installed pure Python modules that need no compiling. It could be A. a problem with my Python install. B. Problem with system gcc compiler … and any number of other system problems. So is there a waf test file, or at least a known good compile on Linux of some other Python module ?

But meanwhile here’s a little sleuthing. The “Checking for header Python.h: :-(” I thought might be a massive clue. Thought I’d missed the obvious ! But Python system “dev” package is installed. But …

“python-config --includes
-I/home/michaelzfreeman/.pyenv/versions/3.5.1/include/python3.5m -I/home/michaelzfreeman/.pyenv/versions/3.5.1/include/python3.5m”

Correct path to “Python.h”.

Then it gives the “Getting pyext flags from python-config: Could not build python extensions” … but …

“python-config --ldflags
-L/home/michaelzfreeman/.pyenv/versions/3.5.1/lib/python3.5/config-3.5m -L/home/michaelzfreeman/.pyenv/versions/3.5.1/lib -lpython3.5m -lpthread -ldl -lutil -lm -Xlinker -export-dynamic”

“pyext” is installed and I can see it.

But looking at “waf” config.log: http://files.djbarney.org/config.log

… (that I did not see before, don’t why this it not reported to console) shows the real meat of the errors starting at line 418 …
“[’/usr/bin/g++’, ‘-shared’, ‘-pthread’, ‘test.cpp.1.o’, ‘-o’, ‘/tmp/pip-build-k2pgcq1x/wxPython-Phoenix/build/waf/3.5/.conf_check_9814a9ffc41959a7044afc7703702a3d/testbuild/testprog.cpython-35m-x86_64-linux-gnu.so’, ‘-Wl,-Bstatic’, ‘-Wl,-Bdynamic’, ‘-L/home/michaelzfreeman/.pyenv/versions/3.5.1/lib’, ‘-L/home/michaelzfreeman/.pyenv/versions/3.5.1/lib/python3.5/config-3.5m’, ‘-lpython3.5m’, ‘-lpthread’, ‘-ldl’, ‘-lutil’, ‘-lm’]
err: /usr/bin/ld: /home/michaelzfreeman/.pyenv/versions/3.5.1/lib/libpython3.5m.a(pylifecycle.o): relocation R_X86_64_32 against `.rodata.str1.1’ can not be used when making a shared object; recompile with -fPIC
/home/michaelzfreeman/.pyenv/versions/3.5.1/lib/libpython3.5m.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status”

Could be some kind of 64 bit/32bit mismatch ? But I’m wildly guessing here.

So I need to find a way of testing my build environment first before proceeding (see top).

Michael Z Freeman

Robin · July 12, 2019, 9:32pm

I don’t know anything about pyenv, but is there any reason to not use Python 3.5’s built-in virtual environment tool? Make sure that Ubuntu’s Python 3.5 package and the corresponding -dev package are installed, download a Phoenix source tar file, and then try something like this:

mkdir ~/tmp-phoenix-build

cd ~/tmp-phoenix-build

pyvenv-3.5 my-py35

source my-py35/bin/activate

pip install -U pip setuptools six wheel

pip wheel wxPython_Phoenix-3.0.3.dev2472+78ae39a.tar.gz

You should end up with a .whl file in ~/tmp-phoenix-build
which you can install in this or other compatible Python 3.5 environments (real or virtual) on your machine.

Robin

Michael Freeman wrote:

···

http://files.djbarney.org/config.log

Michael_Freeman · July 12, 2019, 9:32pm

Thanks. Same error. BTW, if you don’t know already, “pyenv” installs a fully built installation of Python just as if I had downloaded the source code it myself from the Python site and built then installed.
There’s things like “err: /usr/bin/ld: cannot find -lpython3.5” in http://files.djbarney.org/config.log.txt
Look at around line 102 … *"-L/home/michaelzfreeman/.pyenv/versions/3.5.1/lib’, ‘-lpython3.5’] not found".*If I’m correct, it’s like the build script is looking for what should be the system libraries (“libpython3.5-dev”) in the virtual environment and not finding them. I’ll try setting some system variables to point the build to the correct python libraries.

So where are all the Linux experts in this forum ? I really need to get this build working.

MichaelZFreeman

···

On Friday, September 2, 2016 at 12:44:24 AM UTC+1, Robin Dunn wrote:

I don’t know anything about pyenv, but is there any reason to not use Python 3.5’s built-in virtual environment tool? Make sure that Ubuntu’s Python 3.5 package and the corresponding -dev package are installed, download a Phoenix source tar file, and then try something like this:

mkdir ~/tmp-phoenix-build

cd ~/tmp-phoenix-build

pyvenv-3.5 my-py35

source my-py35/bin/activate

pip install -U pip setuptools six wheel

pip wheel wxPython_Phoenix-3.0.3.dev2472+78ae39a.tar.gz

You should end up with a .whl file in ~/tmp-phoenix-build
which you can install in this or other compatible Python 3.5 environments (real or virtual) on your machine.

Robin

Michael Freeman wrote:

OK. I looked at this again.

First I don’t know how to confirm that my Linux (Ubuntu Xenial) Python
waf build system (in a “pyenv”) is actually fully functional. This should be done first as I’ve only ever installed pure Python modules that need no compiling. It could be A. a problem with my Python install.
B. Problem with system gcc compiler … and any number of other system problems. So is there a waf test file, or at least a known good compile on Linux of some other Python module ?

But meanwhile here’s a little sleuthing. The “Checking for header Python.h: :-(” I thought might be a massive clue. Thought I’d missed the obvious ! But Python system “dev” package is installed. But …

“python-config --includes
-I/home/michaelzfreeman/.pyenv/versions/3.5.1/include/ python3.5m
-I/home/michaelzfreeman/.pyenv/versions/3.5.1/include/python3.5m”

Correct
path to “Python.h”.

Then it gives the “Getting pyext flags from python-config: Could not build python extensions” … but …

“python-config
–ldflags
-L/home/michaelzfreeman/.pyenv/versions/3.5.1/lib/ python3.5/config-3.5m
-L/home/michaelzfreeman/.pyenv/versions/3.5.1/lib -lpython3.5m -lpthread -ldl -lutil -lm -Xlinker -export-dynamic”

“pyext” is installed and I can see it.

But looking at “waf” config.log: http://files.djbarney.org/config.log

… (that I did not see before, don’t why this it not reported to console) shows the real meat of the errors starting at line 418 …
“[’/usr/bin/g++’, ‘-shared’, ‘-pthread’, ‘test.cpp.1.o’, ‘-o’, '/tmp/pip-build-k2pgcq1x/wxPython-Phoenix/build/waf/3.5/.conf_check_9814a9ffc41959a7044afc7703702a3d/testbuild/testprog.cpython-35m-x86_64-linux-gnu.so ‘,
‘-Wl,-Bstatic’, ‘-Wl,-Bdynamic’, ‘-L/home/michaelzfreeman/.pyenv/versions/3.5.1/lib’, ‘-L/home/michaelzfreeman/.pyenv/versions/3.5.1/lib/ python3.5/config-3.5m’,
‘-lpython3.5m’, ‘-lpthread’, ‘-ldl’, ‘-lutil’, ‘-lm’]
err: /usr/bin/ld: /home/michaelzfreeman/.pyenv/versions/3.5.1/lib/libpython3. 5m.a(pylifecycle.o):
relocation R_X86_64_32 against `.rodata.str1.1’ can not be used when making a shared object; recompile with -fPIC
/home/michaelzfreeman/.pyenv/versions/3.5.1/lib/libpython3. 5m.a:
error adding symbols: Bad value
collect2: error: ld returned 1 exit status”

Could be some kind of 64 bit/32bit mismatch ? But I’m wildly guessing here.

So I need to find a way of testing my build
environment first before proceeding (see top).

Michael Z Freeman

–

You received this message because you are subscribed to the Google Groups “wxPython-dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to wxPython-dev...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Robin · July 12, 2019, 9:32pm

I’ve just set up a new Ubuntu 16.04 VM and tried my recipe below using a
Python 3.5 venv (just to make sure it’s clear, that is not the same thing as the pyenv tool you are using) and it was successful. The build
automatically will look in the base (system in this case) Python for headers and libs and things that are not in the venv, because it is using python itself to give the location of those things.

There was one unexepected error on the first try, but it turned out that
I hadn’t installed one of the python -dev packages. I had installed libpython3.5-dev but not python3.5-dev. You’ll also need python3.5-venv.

On the other hand, a bit of googling turned up some similar issues with pyenv that you are having. Apparently it does not default to building Python with the --enable-shared configure flag, and so it static links everything into the python executable instead of creating the library that waf is looking for. The following link is about OSX, but other pages about the problem on Linux pointed to this page too.

HTH,
Robin
Michael Freeman wrote:

···

https://github.com/yyuu/pyenv/wiki/Home/_compare/45570ea%5E…45570ea

Michael_Freeman · July 12, 2019, 9:32pm

Yes, thanks Now the build works both with your method and by adding the build flag for the “pyenv” build. At last. A bit of struggle for me because, although I’m familiar with building Linux software from source I’m quite new to Python.

So Blender loads up OK using the “pyenv” Python, but both the build I did in “pyenv” AND the build to a wheel in “venv” (the wheel install replaced the pip built version) throws this error …

“Blender Game Engine Started
Python script error - object ‘Platter’, controller ‘Globals’:
Traceback (most recent call last):
File “getrotation.py”, line 21, in
File “/home/michaelzfreeman/Downloads/blender-2.77-a5261e0-linux-glibc219-x86_64/2.77/python/lib/python3.5/site-packages/wx/init.py”, line 17, in
from wx.core import *
File “/home/michaelzfreeman/Downloads/blender-2.77-a5261e0-linux-glibc219-x86_64/2.77/python/lib/python3.5/site-packages/wx/core.py”, line 12, in
from ._core import *
ImportError: /home/michaelzfreeman/Downloads/blender-2.77-a5261e0-linux-glibc219-x86_64/2.77/python/lib/python3.5/site-packages/wx/_core.cpython-35m-x86_64-linux-gnu.so: symbol _ZNK8wxWindow7IsShownEv, version WXU_3.0 not defined in file libwx_gtk2u_core-3.0.so.0 with link time reference
Python module can’t be imported - object ‘Platter’, controller ‘setPitch’:
Traceback (most recent call last):
File “/home/michaelzfreeman/DJ_Barney_Docs/Docs/Forge/Music/Beat-Research-Forge/DJ Turntable Platter Phyics Simulation/dj_turntable_platter_physics_simulation_96_WITH_WXPYTHON.blend/getrotation.py”, line 21, in
File “/home/michaelzfreeman/Downloads/blender-2.77-a5261e0-linux-glibc219-x86_64/2.77/python/lib/python3.5/site-packages/wx/init.py”, line 12, in
version = wx.version.VERSION_STRING
AttributeError: module ‘wx’ has no attribute ‘version’”

This could be a build flag: “wxPython-dev › wxpython-3.0.0.0 and libnotify” - https://groups.google.com/forum/#!topic/wxpython-dev/DGMlB7Gi4ss

But not being familiar with the build process I’m not sure how to pass the build option.

MichaelZFreeman

···

On Saturday, September 3, 2016 at 4:40:44 AM UTC+1, Robin Dunn wrote:

I’ve just set up a new Ubuntu 16.04 VM and tried my recipe below using a
Python 3.5 venv (just to make sure it’s clear, that is not the same thing as the pyenv tool you are using) and it was successful. The build
automatically will look in the base (system in this case) Python for headers and libs and things that are not in the venv, because it is using python itself to give the location of those things.

There was one unexepected error on the first try, but it turned out that
I hadn’t installed one of the python -dev packages. I had installed libpython3.5-dev but not python3.5-dev. You’ll also need python3.5-venv.

On the other hand, a bit of googling turned up some similar issues with pyenv that you are having. Apparently it does not default to building Python with the --enable-shared configure flag, and so it static links everything into the python executable instead of creating the library that waf is looking for. The following link is about OSX, but other pages about the problem on Linux pointed to this page too.

https://github.com/yyuu/pyenv/wiki/Home/_compare/45570ea%5E…45570ea

HTH,

Robin

Michael Freeman wrote:

Thanks. Same error. BTW, if you don’t know already, “pyenv” installs a fully built installation of Python just as if I had downloaded the source code it myself from the Python site and built then
installed.
There’s things like * “err: /usr/bin/ld: cannot find
-lpython3.5”* in http://files.djbarney.org/config.log.txt
Look
at around line 102 … “-L/home/michaelzfreeman/. pyenv/versions/3.5.1/lib’,
‘-lpython3.5’] not found”. If I’m correct, it’s like the build script is looking for what should be the system libraries (“libpython3.5-dev”) in the virtual environment and not finding them. I’ll try setting some system variables to point the build to the correct
python libraries.

So where are all the Linux experts in this forum ? I really need to get this build working.

MichaelZFreeman

On
Friday, September 2, 2016 at 12:44:24 AM UTC+1, Robin Dunn wrote:

I
don’t know anything about pyenv, but is there any reason to not use Python 3.5’s built-in virtual environment tool? Make sure that Ubuntu’s Python 3.5 package and the corresponding -dev package are installed, download a Phoenix source tar file, and then try something like this:

mkdir
~/tmp-phoenix-build

cd ~/tmp-phoenix-build

pyvenv-3.5 my-py35

source my-py35/bin/activate

pip install -U pip setuptools six wheel

pip wheel wxPython_Phoenix-3.0.3.dev2472+78ae39a.tar.gz

You should end up with a .whl file in
~/tmp-phoenix-build
which you can install in this or other compatible Python 3.5 environments (real or virtual) on your machine.

Robin

Michael Freeman wrote:

OK. I looked at this again.

First
I don’t know how to confirm that my Linux (Ubuntu Xenial) Python
waf build system (in a “pyenv”) is actually fully functional. This should be done first as I’ve only ever installed pure Python modules that need no compiling. It could be A. a problem with my Python install.
B. Problem with system gcc compiler … and any number of other system problems. So is there a waf test file, or at least a known good compile on Linux of some other Python module ?

But meanwhile here’s a little sleuthing. The “Checking for header Python.h: :-(” I thought might be a massive clue. Thought I’d missed the obvious ! But Python system “dev” package is installed. But …

“python-config --includes
-I/home/michaelzfreeman/.pyenv/versions/3.5.1/include/
python3.5m
-I/home/michaelzfreeman/.pyenv/versions/3.5.1/include/python3.5m”

Correct
path to “Python.h”.

Then it gives the “Getting pyext flags from python-config: Could not build python extensions” … but …

“python-config
–ldflags
-L/home/michaelzfreeman/.pyenv/versions/3.5.1/lib/
python3.5/config-3.5m
-L/home/michaelzfreeman/.pyenv/versions/3.5.1/lib -lpython3.5m -lpthread -ldl -lutil -lm -Xlinker -export-dynamic”

“pyext” is installed and I can see it.

But looking at “waf” config.log: http://files.djbarney.org/config.log

… (that I
did not see before, don’t why this it not reported to console) shows the real meat of the errors starting at line 418 …
“[’/usr/bin/g++’, ‘-shared’, ‘-pthread’, ‘test.cpp.1.o’, ‘-o’, '/tmp/pip-build-k2pgcq1x/wxPython-Phoenix/build/waf/3.5/.conf_check_9814a9ffc41959a7044afc7703702a3d/testbuild/testprog.cpython-35m-x86_64-linux-gnu.so ‘,
‘-Wl,-Bstatic’, ‘-Wl,-Bdynamic’, ‘-L/home/michaelzfreeman/.pyenv/versions/3.5.1/lib’, ‘-L/home/michaelzfreeman/.pyenv/versions/3.5.1/lib/
python3.5/config-3.5m’,
‘-lpython3.5m’, ‘-lpthread’, ‘-ldl’, ‘-lutil’, ‘-lm’]
err: /usr/bin/ld: /home/michaelzfreeman/.pyenv/versions/3.5.1/lib/libpython3.
5m.a(pylifecycle.o):
relocation R_X86_64_32 against `.rodata.str1.1’ can not be used when making a shared object; recompile with -fPIC
/home/michaelzfreeman/.pyenv/versions/3.5.1/lib/libpython3.
5m.a:
error adding symbols: Bad value
collect2: error: ld returned 1 exit status”

Could be some kind of 64 bit/32bit mismatch ? But I’m wildly guessing here.

So I need to find a way of testing my build
environment first before proceeding (see top).

Michael Z Freeman

Michael_Freeman · July 12, 2019, 9:32pm

OK, so I made more progress with this.

Tried building with GTK3 but got some build errors with the html parts of wx that I did not get with GTK2.

I’m still trying to see if my error on wx import can be solved by turning off libnotify. I can see the configure options but for the life of me can’t work out how to actually set the configure options. I’ve tried passing them to “waf” using the commands listed by “python build.py --help”. I’ve tried setting " --with-libnotify=np" on various places on the recommended build command line. I tried running “./configure …” first before the main build but that runs configure again.

So how do I set the configure flags ?

Michael Z Freeman

···

On Saturday, September 3, 2016 at 4:40:44 AM UTC+1, Robin Dunn wrote:

I’ve just set up a new Ubuntu 16.04 VM and tried my recipe below using a
Python 3.5 venv (just to make sure it’s clear, that is not the same thing as the pyenv tool you are using) and it was successful. The build
automatically will look in the base (system in this case) Python for headers and libs and things that are not in the venv, because it is using python itself to give the location of those things.

There was one unexepected error on the first try, but it turned out that
I hadn’t installed one of the python -dev packages. I had installed libpython3.5-dev but not python3.5-dev. You’ll also need python3.5-venv.

On the other hand, a bit of googling turned up some similar issues with pyenv that you are having. Apparently it does not default to building Python with the --enable-shared configure flag, and so it static links everything into the python executable instead of creating the library that waf is looking for. The following link is about OSX, but other pages about the problem on Linux pointed to this page too.

https://github.com/yyuu/pyenv/wiki/Home/_compare/45570ea%5E…45570ea

HTH,

Robin

Michael Freeman wrote:

Thanks. Same error. BTW, if you don’t know already, “pyenv” installs a fully built installation of Python just as if I had downloaded the source code it myself from the Python site and built then
installed.
There’s things like * “err: /usr/bin/ld: cannot find
-lpython3.5”* in http://files.djbarney.org/config.log.txt
Look
at around line 102 … “-L/home/michaelzfreeman/. pyenv/versions/3.5.1/lib’,
‘-lpython3.5’] not found”. If I’m correct, it’s like the build script is looking for what should be the system libraries (“libpython3.5-dev”) in the virtual environment and not finding them. I’ll try setting some system variables to point the build to the correct
python libraries.

So where are all the Linux experts in this forum ? I really need to get this build working.

MichaelZFreeman

On
Friday, September 2, 2016 at 12:44:24 AM UTC+1, Robin Dunn wrote:

I
don’t know anything about pyenv, but is there any reason to not use Python 3.5’s built-in virtual environment tool? Make sure that Ubuntu’s Python 3.5 package and the corresponding -dev package are installed, download a Phoenix source tar file, and then try something like this:

mkdir
~/tmp-phoenix-build

cd ~/tmp-phoenix-build

pyvenv-3.5 my-py35

source my-py35/bin/activate

pip install -U pip setuptools six wheel

pip wheel wxPython_Phoenix-3.0.3.dev2472+78ae39a.tar.gz

You should end up with a .whl file in
~/tmp-phoenix-build
which you can install in this or other compatible Python 3.5 environments (real or virtual) on your machine.

Robin

Michael Freeman wrote:

OK. I looked at this again.

First
I don’t know how to confirm that my Linux (Ubuntu Xenial) Python
waf build system (in a “pyenv”) is actually fully functional. This should be done first as I’ve only ever installed pure Python modules that need no compiling. It could be A. a problem with my Python install.
B. Problem with system gcc compiler … and any number of other system problems. So is there a waf test file, or at least a known good compile on Linux of some other Python module ?

But meanwhile here’s a little sleuthing. The “Checking for header Python.h: :-(” I thought might be a massive clue. Thought I’d missed the obvious ! But Python system “dev” package is installed. But …

“python-config --includes
-I/home/michaelzfreeman/.pyenv/versions/3.5.1/include/
python3.5m
-I/home/michaelzfreeman/.pyenv/versions/3.5.1/include/python3.5m”

Correct
path to “Python.h”.

Then it gives the “Getting pyext flags from python-config: Could not build python extensions” … but …

“python-config
–ldflags
-L/home/michaelzfreeman/.pyenv/versions/3.5.1/lib/
python3.5/config-3.5m
-L/home/michaelzfreeman/.pyenv/versions/3.5.1/lib -lpython3.5m -lpthread -ldl -lutil -lm -Xlinker -export-dynamic”

“pyext” is installed and I can see it.

But looking at “waf” config.log: http://files.djbarney.org/config.log

… (that I
did not see before, don’t why this it not reported to console) shows the real meat of the errors starting at line 418 …
“[’/usr/bin/g++’, ‘-shared’, ‘-pthread’, ‘test.cpp.1.o’, ‘-o’, '/tmp/pip-build-k2pgcq1x/wxPython-Phoenix/build/waf/3.5/.conf_check_9814a9ffc41959a7044afc7703702a3d/testbuild/testprog.cpython-35m-x86_64-linux-gnu.so ‘,
‘-Wl,-Bstatic’, ‘-Wl,-Bdynamic’, ‘-L/home/michaelzfreeman/.pyenv/versions/3.5.1/lib’, ‘-L/home/michaelzfreeman/.pyenv/versions/3.5.1/lib/
python3.5/config-3.5m’,
‘-lpython3.5m’, ‘-lpthread’, ‘-ldl’, ‘-lutil’, ‘-lm’]
err: /usr/bin/ld: /home/michaelzfreeman/.pyenv/versions/3.5.1/lib/libpython3.
5m.a(pylifecycle.o):
relocation R_X86_64_32 against `.rodata.str1.1’ can not be used when making a shared object; recompile with -fPIC
/home/michaelzfreeman/.pyenv/versions/3.5.1/lib/libpython3.
5m.a:
error adding symbols: Bad value
collect2: error: ld returned 1 exit status”

Could be some kind of 64 bit/32bit mismatch ? But I’m wildly guessing here.

So I need to find a way of testing my build
environment first before proceeding (see top).

Michael Z Freeman

Robin · July 12, 2019, 9:32pm

Michael Freeman wrote:

So Blender loads up OK using the "pyenv" Python, but both the build I
did in "pyenv" *AND* the build to a wheel in "venv" (the wheel install
replaced the pip built version) throws this error ...

...

from ._core import *
ImportError:
/home/michaelzfreeman/Downloads/blender-2.77-a5261e0-linux-glibc219-x86_64/2.77/python/lib/python3.5/site-packages/wx/_core.cpython-35m-x86_64-linux-gnu.so:
symbol _ZNK8wxWindow7IsShownEv, version WXU_3.0 not defined in file
libwx_gtk2u_core-3.0.so.0 with link time reference

Does the same thing happen if you import wx in a Python session (which
has your Phoenix wheel installed) outside of the Blender environment?
(I wasn't sure if this is what you meant in the second half of your
opening statement above.)

Errors like this could happen if the system is loading the wrong version
of a shared library, for example if it loads a lib different than the
one it was linked with at build time. On linux you can use the ldd
command to determine where shared libraries are coming from, try this:

ldd
/home/michaelzfreeman/Downloads/blender-2.77-a5261e0-linux-glibc219-x86_64/2.77/python/lib/python3.5/site-packages/wx/_core.cpython-35m-x86_64-linux-gnu.so

and there should be a line in the output that shows the full path to the
libwx_gtk2u_core-3.0.so.0 it is loading. For a normal Phoenix build
(without flags telling it to use a different wxWidgets or etc.) then it
should use the libwx_* files in the same folder as the Phoenix extension
modules. If it does show it using that lib then perhaps Blender is
setting something in the environment that is preventing the dynamic
loader from using the rpath set in the Phoenix modules, and it is
looking in the system or Blender libs location or something instead. So
if you can repeat that command inside of Blender somehow then that may
give some clues as well.

This could be a build flag: "wxPython-dev › wxpython-3.0.0.0 and
libnotify" -
https://groups.google.com/forum/#!topic/wxpython-dev/DGMlB7Gi4ss
<https://groups.google.com/forum/#!topic/wxpython-dev/DGMlB7Gi4ss>

The missing symbol doesn't have anything to do with the libnotify
functionality.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org

Michael_Freeman · July 12, 2019, 9:32pm

Does the same thing happen if you import wx in a Python session (which

has your Phoenix wheel installed) outside of the Blender environment?
(I wasn’t sure if this is what you meant in the second half of your

opening statement above.)

Yes, see python console output below. I used “python build.py install”. Is that correct, or do I have to build a wheel and install that ?

Errors like this could happen if the system is loading the wrong version

of a shared library, for example if it loads a lib different than the

one it was linked with at build time. On linux you can use the ldd

command to determine where shared libraries are coming from, try this:
ldd
/home/michaelzfreeman/Downloads/blender-2.77-a5261e0-linux-glibc219-x86_64/2.77/python/lib/python3.5/site-packages/wx/_core.cpython-35m-x86_64-linux-gnu.so

Lo and behold its loading the system library, not the Phoenix one. See output below.

MichaelZFreeman@linux-freeman-G41MT-S2PT ~
$ python
Python 3.5.1 (default, Sep 3 2016, 13:09:54)
[GCC 5.4.0 20160609] on linux
Type “help”, “copyright”, “credits” or “license” for more information.

import wx
Traceback (most recent call last):
File “”, line 1, in
File “/home/michaelzfreeman/.pyenv/versions/3.5.1/lib/python3.5/site-packages/wx/init.py”, line 17, in
from wx.core import *
File “/home/michaelzfreeman/.pyenv/versions/3.5.1/lib/python3.5/site-packages/wx/core.py”, line 12, in
from ._core import *
ImportError: /home/michaelzfreeman/.pyenv/versions/3.5.1/lib/python3.5/site-packages/wx/_core.cpython-35m-x86_64-linux-gnu.so: symbol _ZNK8wxWindow7IsShownEv, version WXU_3.0 not defined in file libwx_gtk2u_core-3.0.so.0 with link time reference

MichaelZFreeman@linux-freeman-G41MT-S2PT ~/ReturnToTheSource/Phoenix
$ ldd /home/michaelzfreeman/Downloads/blender-2.77-a5261e0-linux-glibc219-x86_64/2.77/python/lib/python3.5/site-packages/wx/_core.cpython-35m-x86_64-linux-gnu.so
linux-vdso.so.1 => (0x00007ffc1892c000)
libwx_gtk2u_core-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0 (0x00007fcbbdaed000)
libwx_baseu_net-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0 (0x00007fcbbd8a1000)
libwx_baseu-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 (0x00007fcbbd40e000)
libpython3.5m.so.1.0 => /home/michaelzfreeman/.pyenv/versions/3.5.1/lib/libpython3.5m.so.1.0 (0x00007fcbbcef6000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fcbbcb74000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcbbc86a000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fcbbc654000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcbbc28b000)
libgtk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 (0x00007fcbbbc3f000)
libgdk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 (0x00007fcbbb98a000)
libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007fcbbb77d000)
libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2 (0x00007fcbbb468000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007fcbbb246000)
libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007fcbbaffa000)
libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007fcbbada6000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007fcbbaa95000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007fcbba75b000)
libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007fcbba554000)
libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x00007fcbba34c000)
libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007fcbba11a000)
libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007fcbb9ec0000)
libtiff.so.5 => /usr/lib/x86_64-linux-gnu/libtiff.so.5 (0x00007fcbb9c4d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fcbb9a30000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fcbb9815000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fcbb9611000)
/lib64/ld-linux-x86-64.so.2 (0x000055d56b29f000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fcbb940d000)
libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007fcbb9209000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007fcbb9002000)
libatk-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007fcbb8ddd000)
libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007fcbb8a55000)
libpangoft2-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007fcbb883f000)
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007fcbb85fb000)
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007fcbb83f1000)
libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007fcbb81ed000)
libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007fcbb7fdd000)
libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007fcbb7dd2000)
libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007fcbb7bc8000)
libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007fcbb79c4000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007fcbb77c1000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007fcbb75af000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007fcbb7304000)
libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007fcbb705c000)
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007fcbb6e36000)
libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007fcbb6c32000)
libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007fcbb6a28000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fcbb6805000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fcbb65fd000)
libthai.so.0 => /usr/lib/x86_64-linux-gnu/libthai.so.0 (0x00007fcbb63f3000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fcbb61eb000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fcbb5f7b000)
libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 (0x00007fcbb5d60000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fcbb5b5b000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fcbb5939000)
libjbig.so.0 => /usr/lib/x86_64-linux-gnu/libjbig.so.0 (0x00007fcbb572a000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fcbb5508000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fcbb52ec000)
libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007fcbb508e000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007fcbb4e65000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fcbb4c60000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fcbb4a5a000)
libdatrie.so.1 => /usr/lib/x86_64-linux-gnu/libdatrie.so.1 (0x00007fcbb4851000)
libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007fcbb462c000)

···

On Monday, September 5, 2016 at 7:34:46 PM UTC+1, Robin Dunn wrote:

Michael_Freeman · July 12, 2019, 9:32pm

Plus … https://github.com/yyuu/pyenv/issues/65#issuecomment-26925720

"I found a better way to do it that doesn’t depend on pyenv setting LD_LIBRARY_PATH:
PYTHON_CONFIGURE_OPTS='--enable-shared' LDFLAGS="-Wl,-rpath=$HOME/.pyenv/versions/2.7.5/lib" pyenv install 2.7.5

This will add the the python lib directory to the rpath of the python
executable. The rpath is searched before LD_LIBRARY_PATH and ld.conf.so, so there’s no way pyenv’s installed python will try to load the system’s libpython which may be of a different version."

So it could be another config option for penv, but it’s late here now and I need a beer

Michael_Freeman · July 12, 2019, 9:32pm

So, finally, I got past the current error. It was pyenv ! I posted them an issue: https://github.com/yyuu/pyenv/issues/691

On to the next error.

But
first I could just use wx in Windows but I chose Phoenix because its cross platform (nad it has to be Python 3 because of Blender). I don’t want to restrict myself and other users to just Windows for the project.
So what is the status of Phoenix ? Are these just a few random bugs or is Phoenix still some way off “prime time” as it were ? I don’t mind helping with the development but will have to consider another Python GUI module eventually as I can’t spend all my time on this.

So …

So, finally, I got past the current error. It was pyenv ! I posted them an issue: https://github.com/yyuu/pyenv/issues/691

On to the next error.

But
first I could just use wx in Windows but I chose Phoenix because its cross platform (nad it has to be Python 3 because of Blender). I don’t want to restrict myself and other users to just Windows for the project.
So what is the status of Phoenix ? Are these just a few random bugs or is Phoenix still some way off “prime time” as it were ? I don’t mind helping with the development but will have to consider another Python GUI module eventually as I can’t spend all my time on this.

So … Phoenix built with system compiled Python 3.5.1 from official source. Made into main system Python (NO pyenv) by using Ubuntu/Debian “alternatives” system:

MichaelZFreeman@linux-freeman-G41MT-S2PT ~
$ python
Python 3.5.1 (default, Sep 7 2016, 11:35:13)
[GCC 5.4.0 20160609] on linux
Type “help”, “copyright”, “credits” or “license” for more information.

import wx
Traceback (most recent call last):
File “”, line 1, in
File “/opt/python3.5.1/lib/python3.5/site-packages/wx/init.py”, line 17, in
from wx.core import *
File “/opt/python3.5.1/lib/python3.5/site-packages/wx/core.py”, line 12, in
from ._core import *
ImportError: dynamic module does not define module export function (PyInit__core)

import wx
Traceback (most recent call last):
File “”, line 1, in
File “/opt/python3.5.1/lib/python3.5/site-packages/wx/init.py”, line 12, in
version = wx.version.VERSION_STRING
AttributeError: module ‘wx’ has no attribute ‘version’

import wx
Traceback (most recent call last):
File “”, line 1, in
File “/opt/python3.5.1/lib/python3.5/site-packages/wx/init.py”, line 12, in
version = wx.version.VERSION_STRING
AttributeError: module ‘wx’ has no attribute ‘version’

“ldd” shows correct library loading …

MichaelZFreeman@linux-freeman-G41MT-S2PT ~
$ ldd /opt/python3.5.1/lib/python3.5/site-packages/wx/_core.cpython-35m-x86_64-linux-gnu.so
linux-vdso.so.1 => (0x00007ffc7becf000)
libwx_gtk2u_core-3.0.so.0 => /opt/python3.5.1/lib/python3.5/site-packages/wx/libwx_gtk2u_core-3.0.so.0 (0x00007fa9b3180000)
libwx_baseu_net-3.0.so.0 => /opt/python3.5.1/lib/python3.5/site-packages/wx/libwx_baseu_net-3.0.so.0 (0x00007fa9b2f31000)
libwx_baseu-3.0.so.0 => /opt/python3.5.1/lib/python3.5/site-packages/wx/libwx_baseu-3.0.so.0 (0x00007fa9b2a8f000)
libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x00007fa9b24d6000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fa9b2154000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa9b1e4a000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa9b1c34000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa9b186b000)
libgtk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 (0x00007fa9b121f000)
libgdk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 (0x00007fa9b0f6a000)
libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007fa9b0d5d000)
libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2 (0x00007fa9b0a48000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007fa9b0826000)
libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007fa9b05da000)
libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007fa9b0386000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007fa9b0075000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007fa9afd3b000)
libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007fa9afb34000)
libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x00007fa9af92c000)
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007fa9af707000)
libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007fa9af4ad000)
libtiff.so.5 => /usr/lib/x86_64-linux-gnu/libtiff.so.5 (0x00007fa9af23a000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa9af01d000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fa9aee02000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa9aebfe000)
/lib64/ld-linux-x86-64.so.2 (0x000055f484122000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fa9ae9fa000)
libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007fa9ae7f6000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007fa9ae5ef000)
libatk-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007fa9ae3ca000)
libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007fa9ae042000)
libpangoft2-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007fa9ade2c000)
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007fa9adbe8000)
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007fa9ad9de000)
libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007fa9ad7da000)
libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007fa9ad5ca000)
libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007fa9ad3bf000)
libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007fa9ad1b5000)
libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007fa9acfb1000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007fa9acdae000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007fa9acb9c000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007fa9ac8f1000)
libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007fa9ac649000)
libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007fa9ac444000)
libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007fa9ac23a000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fa9ac018000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fa9abe0f000)
libthai.so.0 => /usr/lib/x86_64-linux-gnu/libthai.so.0 (0x00007fa9abc06000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fa9ab9fd000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fa9ab78d000)
libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 (0x00007fa9ab573000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fa9ab36d000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fa9ab14b000)
libjbig.so.0 => /usr/lib/x86_64-linux-gnu/libjbig.so.0 (0x00007fa9aaf3d000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fa9aad1a000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fa9aaaff000)
libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007fa9aa8a0000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007fa9aa677000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fa9aa472000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fa9aa26c000)
libdatrie.so.1 => /usr/lib/x86_64-linux-gnu/libdatrie.so.1 (0x00007fa9aa064000)
libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007fa9a9e3e000)

···

On Monday, September 5, 2016 at 7:34:46 PM UTC+1, Robin Dunn wrote:

Michael Freeman wrote:

So Blender loads up OK using the “pyenv” Python, but both the build I

did in “pyenv” AND the build to a wheel in “venv” (the wheel install

replaced the pip built version) throws this error …

Michael_Freeman · July 12, 2019, 9:32pm

Apologies for the repeated replies, but you’ll be glad to know that I finally got it working !

Screenshot: http://files.djbarney.org/blender_dj_turntable_wxPython_Phoenix_LINUX_file_open.png

The last error was due to something to do with having to use “python3” not “python” for the compilation for a reason I don’t pretend to understand. Here is the description of the same issue someone else had: http://stackoverflow.com/questions/36723206/cython-compilation-error-dynamic-module-does-not-define-module-export-function

So that made the build command: /opt/python3.5.1/bin/python3.5 build.py -j 7 dox etg --nodoc sip build 2>&1 | tee phoenix_build_output.txt

Demo’s appear to run OK (apart from “demo.py” which get’s stuck with 100% cpu usage but I assume it’s huge and did not wait for completion).

So thanks for the help, it’s been fun but a HUGE saga for me (long story).

If I can help building wheel’s for distribution in any way then please say.

Cheers

Michael Z Freeman

···

On Monday, September 5, 2016 at 7:34:46 PM UTC+1, Robin Dunn wrote:

Michael Freeman wrote:

So Blender loads up OK using the “pyenv” Python, but both the build I

did in “pyenv” AND the build to a wheel in “venv” (the wheel install

replaced the pip built version) throws this error …

…
from ._core import *
ImportError:

/home/michaelzfreeman/Downloads/blender-2.77-a5261e0-linux-glibc219-x86_64/2.77/python/lib/python3.5/site-packages/wx/_core.cpython-35m-x86_64-linux-gnu.so:

symbol _ZNK8wxWindow7IsShownEv, version WXU_3.0 not defined in file

libwx_gtk2u_core-3.0.so.0 with link time reference

Does the same thing happen if you import wx in a Python session (which

has your Phoenix wheel installed) outside of the Blender environment?
(I wasn’t sure if this is what you meant in the second half of your

opening statement above.)

Errors like this could happen if the system is loading the wrong version

of a shared library, for example if it loads a lib different than the

one it was linked with at build time. On linux you can use the ldd

command to determine where shared libraries are coming from, try this:
ldd
/home/michaelzfreeman/Downloads/blender-2.77-a5261e0-linux-glibc219-x86_64/2.77/python/lib/python3.5/site-packages/wx/_core.cpython-35m-x86_64-linux-gnu.so

and there should be a line in the output that shows the full path to the

libwx_gtk2u_core-3.0.so.0 it is loading. For a normal Phoenix build

(without flags telling it to use a different wxWidgets or etc.) then it

should use the libwx_* files in the same folder as the Phoenix extension

modules. If it does show it using that lib then perhaps Blender is

setting something in the environment that is preventing the dynamic

loader from using the rpath set in the Phoenix modules, and it is

looking in the system or Blender libs location or something instead. So

if you can repeat that command inside of Blender somehow then that may

give some clues as well.

This could be a build flag: "wxPython-dev › wxpython-3.0.0.0 and

libnotify" -

https://groups.google.com/forum/#!topic/wxpython-dev/DGMlB7Gi4ss

<https://groups.google.com/forum/#%21topic/wxpython-dev/DGMlB7Gi4ss>

The missing symbol doesn’t have anything to do with the libnotify

functionality.

–
Robin Dunn

Software Craftsman

http://wxPython.org

Robin · July 12, 2019, 9:32pm

Michael Freeman wrote:

The last error was due to something to do with having to use "python3"
not "python" for the compilation for a reason I don't pretend to
understand. Here is the description of the same issue someone else
had:
http://stackoverflow.com/questions/36723206/cython-compilation-error-dynamic-module-does-not-define-module-export-function

So that made the build command: /opt/python3.5.1/bin/python3.5
build.py -j 7 dox etg --nodoc sip build 2>&1 | tee
phoenix_build_output.txt

Yes, when building any Python extension module it is important to use
the same Python you are intending to use the built module with. On your
system "python" is probably a symlink to python2.7 and the command
"python3" to the python3.5 binary. Look at `ls -l /usr/bin/python*` to
check.

Demo's appear to run OK (apart from "demo.py" which get's stuck with
100% cpu usage but I assume it's huge and did not wait for completion).

You shouldn't need to. The main demo starts up with just a small-ish
app and doesn't load the rest of the demo modules until they are
selected. If it was stuck then something unexpected is happening and it
would be good to investigate it.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org

Robin · July 12, 2019, 9:32pm

Michael Freeman wrote:

So, finally, I got past the current error. It was pyenv ! I posted
them an issue: https://github.com/yyuu/pyenv/issues/691

Which was why I suggested trying it in a normal Python virtualenv or
venv that was created from the stock Python on your system, instead of
using pyenv's custom builds.

But first I could just use wx in Windows but I chose Phoenix because
its cross platform (nad it has to be Python 3 because of Blender). I
don't want to restrict myself and other users to just Windows for the
project. So what is the status of Phoenix ? Are these just a few
random bugs or is Phoenix still some way off "prime time" as it were ?
I don't mind helping with the development but will have to consider
another Python GUI module eventually as I can't spend all my time on this.

The plan is to have an official alpha soonish, once I have completed
some of the things I have in progress right now. The actual content of
the alpha won't be much different than what is in the snapshot builds
currently. But the plan is to also start putting it on PyPI, so it will
end up being more of an implementation and test of a new release
process, and also a means of making a statement to the community that
Phoenix is usable. After the first (and maybe only?) alpha it will be
time to evaluate what features are still missing before making a beta
release and those will be worked on next.

For anybody wanting to help out, here are some things currently on my radar:

* The wx.lib modules and subpackages have had a lot of work already for
porting to Phoenix and also adding some docstrings and such, but I think
there is still more work to be done there. I've seen some errors
related to Py3 compatibility here and there so it would be good to have
somebody go over all of the modules testing and fixing any Py3 issues
that are discovered. I haven't reviewed the wx.lib.agw modules much at
all yet, so that would be a good place to start. Another place that
needs some attention is the wx.lib.masked package.

* There is also the list in the TODO.rst file in the source tree. Some
of those are just nice-to-haves, some are more important.

* I'm currently working on adding wrappers for the propgrid module.
It's mostly done except for some documentation generation tweaks.
However, I've never actually used it myself in an application so when my
current work is merged it would be good for somebody with some
experience with propgrid in Classic to give the API a look, port the
demo or whatever, and determine if there are any greater than expected
compatibility breaks.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org

Michael_Freeman · July 12, 2019, 9:32pm

Michael Freeman wrote:

The last error was due to something to do with having to use “python3”

not “python” for the compilation for a reason I don’t pretend to

understand. Here is the description of the same issue someone else

had:

http://stackoverflow.com/questions/36723206/cython-compilation-error-dynamic-module-does-not-define-module-export-function

So that made the build command: /opt/python3.5.1/bin/python3.5

build.py -j 7 dox etg --nodoc sip build 2>&1 | tee

phoenix_build_output.txt

Yes, when building any Python extension module it is important to use

the same Python you are intending to use the built module with. On your

system “python” is probably a symlink to python2.7 and the command

“python3” to the python3.5 binary. Look at ls -l /usr/bin/python* to

check.

I eventually used the Debian/Ubuntu “alternatives” system ( http://manpages.ubuntu.com/manpages/trusty/man8/update-alternatives.8.html ) which I should have used to begin with. It’s all been complicated by the fact that the Ubuntu system Python is tied into system functions so changing it breaks package updates. I also needed specifically to build against Python 3.5.1 for Blender. I did replace system Python with 3.5.1 using the alternatives system. So “/usr/bin/python” is actually a symlink to python3.5. It’s identical accept for the name difference between “python” in “/usr/bin/” and “python3.5” in “/opt/python3.5.1/bin/”. But, don’t ask me why, that effects compilation of Phoenix leading to the errors quoted above.

Demo’s appear to run OK (apart from “demo.py” which get’s stuck with

100% cpu usage but I assume it’s huge and did not wait for completion).

You shouldn’t need to. The main demo starts up with just a small-ish

app and doesn’t load the rest of the demo modules until they are

selected. If it was stuck then something unexpected is happening and it

would be good to investigate it.

I’ll give that another go.

Michael Freeman wrote:

So, finally, I got past the current error. It was pyenv ! I posted

them an issue: https://github.com/yyuu/pyenv/issues/691

Which was why I suggested trying it in a normal Python virtualenv or

venv that was created from the stock Python on your system, instead of

using pyenv’s custom builds.

Yes, I should have made more of an effort to replace the system python ! But I’d forgotten about the alternatives system until up to recently.

But first I could just use wx in Windows but I chose Phoenix because

its cross platform (nad it has to be Python 3 because of Blender). I

don’t want to restrict myself and other users to just Windows for the

project. So what is the status of Phoenix ? Are these just a few

random bugs or is Phoenix still some way off “prime time” as it were ?

I don’t mind helping with the development but will have to consider

another Python GUI module eventually as I can’t spend all my time on this.

The plan is to have an official alpha soonish, once I have completed

some of the things I have in progress right now. The actual content of

the alpha won’t be much different than what is in the snapshot builds

currently. But the plan is to also start putting it on PyPI, so it will

end up being more of an implementation and test of a new release

process, and also a means of making a statement to the community that
…

I’m not experienced enough to help with any of that yet, I’m too new to wxPython. But we’ve covered a lot of ground here building for Linux that I could put into a guide. I also plan to write a guide, based on the thread here, specifically for Blender users (this may apply to other software bundled with specific Python versions). The central problem with building the wxPython Phoenix wheel/source for Blender on Ubuntu and Debian is that it’s not easy for a normal user to install a specific Python version using the usual “sudo apt-get install”.

Michael Z Freeman

···

On Thursday, September 8, 2016 at 1:46:09 AM UTC+1, Robin Dunn wrote:
On Thursday, September 8, 2016 at 1:49:46 AM UTC+1, Robin Dunn wrote:

–
Robin Dunn

Software Craftsman

http://wxPython.org