Freshly Built Vapoursynth Doesn't Work on Debian Stable -- Failed to initialize VSScript
Opened this issue · 15 comments
Built and installed as per the instructions:
./autogen.sh
./configure
make
sudo make install
Test with
LD_LIBRARY_PATH=/usr/local/lib PYTHONPATH=/usr/local/lib/python3.11/site-packages vspipe --version
and it fails with error message "Failed to initialize VSScript."
The files appear to be in the correct locations:
vapoursynth.so is located in /usr/local/lib/python3.11/site-packages
libvapoursynth.so is located in /usr/local/lib
vspipe is in /usr/local/bin/
I've looked over issue #826, but nothing there seems to help.
Aha! I tried opening a python prompt and
Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import vapoursynth
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "src/cython/vapoursynth.pyx", line 86, in init vapoursynth
TypeError: function() argument 'code' must be code, not str
That sounds promising, but I don't know enough cython to troubleshoot it. (Also, something's happening with line numbers somewhere, since line 86 isn't part of an init function in that file in the source.)
Possibly also relevant: I previously had version R57 installed, but it broke after Debian stable's latest upgrade made python3.9 go away. So I uninstalled it and tried to compile the latest and greatest... Is there maybe something cached somewhere that needs to be deleted?
You have indeed found an exciting new error I haven't seen before. Did you compile it with cython 3.x?
Did you compile it with cython 3.x?
I've just got the system-installed cython3 package from Debian stable. Which you'd think would be version 3, right? But... I'm thinking maybe it's not. It's reporting as 0.29.32-2+b1, and I see that upstream cython was still on 0.29.xx as last December, so, I'm thinking maybe the Debian package name means "cython for python3" rather than "cython version 3" and it's based on upstream version 0.29.32 from last summer. (Just as I was writing, thought to check the package in unstable. Yeah, it's cython3 version 3.0.10. So this is it.)
So, how do I get this working?
Installing cython v3 over the system cython3 is probably going to break things.
If I install it in a venv, can I get the compile to process to use it?
It looks like R63 is the last version that doesn't use cython version 3, is that correct?
Update: Built R63 and it passes the vspipe --version test.
You may pip install cython in a venv, then build and install VS into it.
You may pip install cython in a venv, then build and install VS into it.
Thanks! What do I have to do direct the VS install into the venv?
The vapoursynth-script lib should be able to find the python lib, and found by vspipe. They can be placed at your convenience. It's just the python module that must be installed in the venv.
OK... how do I direct the python module to the venv? Do I need to make a minimal package for pip? Or just cut/paste vapoursynth.so to somewhere?
pip install /dir/containing/setup.py/
This issue isn't related to cython
I did a rebuild with cyton 3.0.10 in stable and the error remain.
This issue isn't related to cython
I did a rebuild with cyton 3.0.10 in stable and the error remain.
Did yo reconfigure?
Rebuild are done with Debian packaging tools and thus always reconfigured.
dh_auto_configure -O-Xjquery.js -O-Xunderscore.js -O-X.la
./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to print strings... printf
checking whether make supports the include directive... yes (GNU style)
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... none
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for file... file
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for gcc... (cached) gcc
checking whether the compiler supports GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to enable C11 features... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) none
checking for g++... g++
checking whether the compiler supports GNU C++... yes
checking whether g++ accepts -g... yes
checking for g++ option to enable C++11 features... none needed
checking dependency style of g++... none
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking for _LARGEFILE_SOURCE value needed for large files... no
checking how to run the C preprocessor... gcc -E
checking whether gcc is Clang... no
checking whether pthreads work with "-pthread" and "-lpthread"... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking whether more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for zimg >= 3.0.5... yes
checking for library containing dlopen... none required
checking for sched_getaffinity... yes
checking for cpuset_getaffinity... no
checking for a Python interpreter with version >= 3... python3
checking for python3... /usr/bin/python3
checking for python3 version... 3.11
checking for python3 platform... linux
checking for GNU default python3 prefix... ${prefix}
checking for GNU default python3 exec_prefix... ${exec_prefix}
checking for python3 script directory (pythondir)... ${PYTHON_PREFIX}/lib/python3.11/site-packages
checking for python3 extension module directory (pyexecdir)... ${PYTHON_EXEC_PREFIX}/lib/python3.11/site-packages
checking for python-3.11-embed... yes
checking for cython3... cython3
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating pc/vapoursynth.pc
config.status: creating pc/vapoursynth-script.pc
config.status: creating Makefile
config.status: executing depfiles commands
config.status: executing libtool commands
From https://stackoverflow.com/questions/2231427/error-when-calling-the-metaclass-bases-function-argument-1-must-be-code-not
You're getting that exception because, despite its class-like name, threading.Condition is a function, and you cannot subclass functions.
Well, I'm embarrassed, I forgot to update my repository and the latest vapoursynth wasn't installed.
I can confirm that vapoursynth 68 build with cython3.0.10 fix this issue
Debian stable amd64
To confirm this issue, just installed VapourSynth on Fedora.
> vspipe
Failed to initialize VSScript
> PYTHONPATH=/usr/lib/python3.12/site-packages vspipe --version
Failed to initialize VSScript
Someone was mentioning that the issue was fixed in VapourSynth 68; Fedora ships 65. Filed an issue at RedHat.
My problem was that python3-vapoursynth was missing. After installing it, it works here.
I too am getting the Failed to initialize VSScript error. I am building R68 from Ubuntu 22.04 LTS.
Edit: Never-mind I also had to update cython to 3.0.10.