I'm trying to compile the [pyo~] external that comes with the Pyo module for DSP in Python http://ajaxsoundstudio.com/software/pyo/. The object uses Pd's old Makefile and does compile, giving me a pyo~.l_ia64 binary file (I'm on Linux, UbuntuStudio 22.04). When I try to load the object in Pd, I get the following error:
/home/alexandros/Documents/Pd/externals/pyo/pyo~.l_ia64: /home/alexandros/Documents/Pd/externals/pyo/pyo~.l_ia64: undefined symbol: _Py_NoneStruct
The same object compiles fine on a Rasbperry Pi 3 and 4.
I also tried to compile it with pd-lib-builder. Here's the Makefile I used, based on the existing Makefile that comes with pyo~.c:
lib.name= pyo~
class.sources= pyo~.c
common.sources= m_pyo.h
cflags= -I"$(PD_INCLUDE)" -I.. -Wno-cast-function-type
-Wno-unused-parameter $(shell python-config --cflags)
ldflags= $(shell python-config --ldflags)
libs= $(shell python-config --libs)
datafiles= pyo-help.pd README.md
PDLIBBUILDER_DIR=../pd-lib-builder/
include$(PDLIBBUILDER_DIR)/Makefile.pdlibbuilder
And here's the output when I type make:
++++ info: using Makefile.pdlibbuilder version 0.6.0
++++ info: using Pd API /usr/include/pd/m_pd.h
++++ info: making target all in lib pyo~
++++ info: making pyo~.o in lib pyo~
cc -DPD -I "/usr/include/pd" -DUNIX -fPIC -I"" -I..
-Wno-cast-function-type -Wno-unused-parameter -I/usr/include/python3.10
-I/usr/include/python3.10 -Wno-unused-result -Wsign-compare -g
-fstack-protector-strong -Wformat -Werror=
format-security -DNDEBUG -g -fwrapv -O2 -Wall -Wall -Wextra -Wshadow
-Winline -Wstrict-aliasing -O3 -ffast-math -funroll-loops
-fomit-frame-pointer -march=core2 -mfpmath=sse -msse -msse2 -msse3 -o
pyo~.o -c pyo~.c
make: *** No rule to make target 'm_pyo.o', needed by 'pyo~.pd_linux'.
Stop.
In the pyo~.c file there's a #include "Python.h". Does this mean that
I should direct the Makefile to find this file? Because no Python.h file
comes with the source code.
Can anyone help?
Am 21. Februar 2023 08:41:48 MEZ schrieb Alexandros adrcki@gmail.com:
ldflags= $(shell python-config --ldflags) libs= $(shell python-config --libs)
[...]
In the pyo~.c file there's a
#include "Python.h". Does this mean that I should direct the Makefile to find this file? Because no Python.h file comes with the source code.
Hopefully so. python.h is a file provided by python, and it is paramount that you build against the header file that matches your python installation. So you must install the python development files (python3-dev, or somesuch).
I'm not up-to-date when it comes to python C-development, but I 'python-config' smells like a deprecated tool.
mfg.sfg.jfd IOhannes
On 21/2/23 20:41, IOhannes m zmölnig wrote:
Am 21. Februar 2023 08:41:48 MEZ schrieb Alexandros adrcki@gmail.com:
ldflags= $(shell python-config --ldflags) libs= $(shell python-config --libs)
[...]
In the pyo~.c file there's a
#include "Python.h". Does this mean that I should direct the Makefile to find this file? Because no Python.h file comes with the source code.Hopefully so. python.h is a file provided by python, and it is paramount that you build against the header file that matches your python installation. So you must install the python development files (python3-dev, or somesuch).
I'm not up-to-date when it comes to python C-development, but I 'python-config' smells like a deprecated tool.
Initially that was python3-config, but in my system, python is
Python3, so I thought I change it to python-config. Is this still a
deprecated tool?
On 2/21/23 20:21, Alexandros wrote:
On 21/2/23 20:41, IOhannes m zmölnig wrote:
Am 21. Februar 2023 08:41:48 MEZ schrieb Alexandros adrcki@gmail.com:
ldflags= $(shell python-config --ldflags) libs= $(shell python-config --libs)
[...]
In the pyo~.c file there's a
#include "Python.h". Does this mean that I should direct the Makefile to find this file? Because no Python.h file comes with the source code.Hopefully so. python.h is a file provided by python, and it is paramount that you build against the header file that matches your python installation. So you must install the python development files (python3-dev, or somesuch).
I'm not up-to-date when it comes to python C-development, but I
'python-config' smells like a deprecated tool.Initially that was python3-config, but in my system,
pythonis Python3, so I thought I change it topython-config. Is this still a deprecated tool?
- i was referring to "<foo>-config" being frowned upon in general, as
it creates ad-hoc tools with non-normalized interfaces. typically, a preferred way is to use pkg-config or similar tools (that provide a standard way to query compiler/linker flags to build things). this is a general observation, but of course the Python folks can still ship (and prefer) their own tool (hence my "I'm not up-to-date when it comes to python C-development")
- i *think* the canonical name for the tool is 'python3-config', and
you should not arbitrarily change that just becaues you happen to have a 'python-config' script lying somewhere on your disk. (afaict, this script can be installed on Debian via the 'python-dev-is-python3' convenience package. i would *not* recommend relying on this, and use canonical names instead (but again, "I'm not up-to-date when it comes to python C-development" so i might be wrong about what the canonical name is).
it turns out that 'pkg-config --cflags python3' resp 'pkg-config --libs python3' should do the trick as well.
in any case, your real problem is, that your library does not link against the python dynamic library (e.g. libpython3.11). i don't know why "python3-config --libs" does not report the apropriate linker flags ("I'm not up-to-date when it comes to python C-development"), but "python3-config --embed --libs" (and you probably should add the '--embed' flag to all invocations of python3-config), as well as "pkg-config --libs python3-embed".
finally: there's an issuetracker for pyo on https://github.com/belangeo/pyo/issues which might be a better place to ask such specific questions.
mfg IOhannes
-
Alexandros -
IOhannes m zmölnig