Windows version compile instructions

I recently came across tg and your version and decided to take a stab at compiling it in windows. I wish I could say I was completely successful, but unfortunately the functionality related to the menu option "Signal" is still not working, but I did manage compile it correctly and with support for the "new-stuff" it's just when trying the signal part that I get an error related to numpy (ImportError: DLL load failed while importing _multiarray_umath), which I believe is path issue, anyway hopefully these steps might be helpful and someone else can crack the puzzle, so onward:

Download and install MSYS2 from https://www.msys2.org/

Add the folder "C:\msys64\ucrt64\bin" to the system path variable

Open the MSYS2 UCRT64

Install the required packages with: pacman -S mingw-w64-ucrt-x86_64-gcc make pkg-config mingw-w64-ucrt-x86_64-gtk3 mingw-w64-ucrt-x86_64-portaudio mingw-w64-ucrt-x86_64-fftw git autoconf automake libtool mingw-w64-ucrt-x86_64-ninja mingw-w64-ucrt-x86_64-python-numpy mingw-w64-ucrt-x86_64-python-scipy mingw-w64-ucrt-x86_64-python-matplotlib mingw-w64-ucrt-x86_64-lapack mingw-w64-ucrt-x86_64-cython mingw-w64-ucrt-x86_64-python-setuptools mingw-w64-ucrt-x86_64-python-pip

Grab the libtfr library: git clone https://github.com/melizalab/libtfr.git

Install libtfr cd libtfr python setup.py install cd ..

Grab tg: git clone https://github.com/xyzzy42/tg.git git checkout new-stuff

Open the file src\audio.c and add #include <unistd.h> right after #include <errno.h> and then on the terminal:

./autogen.sh ./configure make

If all went well you should have a tg-timer.exe on your MSYS2 tg folder, that you can now execute with ./tg-timer.exe

Thanks for the information. I think the list of packages to install will be helpful.

The Python code isn't initialized until it's used the first time, and that happens via the Signal dialog or the Filter chain dialog. So I think some DLL is not found, and that triggers when it tries to load python when those buttons are clicked.

It does look like you installed python-numpy, presumably that missing DLL should have been part of it.

Maybe there is some path needed when linking? I have made a branch, https://github.com/xyzzy42/tg/tree/debug-python-autoconf

Give that a test. Re-run the autogen.sh and configure step. It should print out some extra python variables when configure is run, I would be interested in what is in them, and also add them to the build flags. Perhaps they will add some python dll search path to the executable.

Yes, numpy is installed, in fact I even tried different versions and also tried building it from source to no avail, always the same error. I do think that there's something missing, probably some path, because if I open python on msys and run the line that seems to be causing the issue, it works properly with no error. I did found out that I was missing one more package though, I checked the dependencies of the _multiarray_umath .pyd file, and I found that it required libopenblas.dll, so pacman -S mingw-w64-ucrt-x86_64-openblas, the file got installed but no dice still the same problem. I also tried all of this process on the mingw64 environment with the same results. On a positive note, I did found a way to make it run correctly (haven't fully tested it) but it's a hack. I copied tg-timer.exe to C:\msys64\ucrt64\bin (or C:\msys64\mingw64\bin if using mingw64), now simply running tg-timer from the terminal runs tg and I get no errors, in fact if I ignore the terminal and simply go to the folder and double-click tg-timer.exe it also seems to work properly.

Here is the result from ./configure from the new branch: $ ./configure configure: loading site script /etc/config.site 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... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe 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 whether make supports the include directive... yes (GNU style) checking dependency style of gcc... gcc3 checking for pthread_mutex_init in -lpthread... yes checking for sqrt in -lm... yes checking for aligned_alloc... no checking for _aligned_malloc... yes checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for gtk+-3.0 glib-2.0... yes checking for portaudio-2.0... yes checking for fftw3f... yes checking for a Python interpreter with version >= 3.1... python checking for python... /ucrt64/bin/python checking for python version... 3.11 checking for python platform... win32 checking for GNU default python prefix... ${prefix} checking for GNU default python exec_prefix... ${exec_prefix} checking for python script directory (pythondir)... ${PYTHON_PREFIX}/lib/python3.11/site-packages checking for python extension module directory (pyexecdir)... ${PYTHON_EXEC_PREFIX}/lib/python3.11/site-packages 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 python3.11... (cached) /ucrt64/bin/python checking for a version of Python >= '2.1.0'... yes checking for a version of Python >= '3.1'... yes checking for the sysconfig Python package... yes checking for Python include path... -IC:/msys64/ucrt64/include/python3.11 checking for Python library path... -LC:/msys64/ucrt64/lib -lpython3.11 checking for Python site-packages path... /ucrt64/lib/python3.11/site-packages checking for Python platform specific site-packages path... /ucrt64/lib/python3.11/site-packages checking python extra libraries... -lversion -lshlwapi -lpathcch -lbcrypt -lm checking python extra linking flags... -Wl,--stack,2000000 checking consistency of all components of python development environment... yes checking if Python building works... yes checking for Python package numpy... yes checking for Numpy header path... C:/msys64/ucrt64/lib/python3.11/site-packages/numpy/core/include checking for numpy/ndarrayobject.h... yes checking for Python package libtfr... yes checking for Python package scipy... yes checking for Python package matplotlib... yes configure: ---------------- Extra flags for python -------------------- configure: libs -LC:/msys64/ucrt64/lib -lpython3.11 configure: extra libs -lversion -lshlwapi -lpathcch -lbcrypt -lm configure: extra ldflags -Wl,--stack,2000000 configure: cppflags -IC:/msys64/ucrt64/include/python3.11 -IC:/msys64/ucrt64/lib/python3.11/site-packages/numpy/core/include configure: ------------------------------------------------------------- checking for windres... windres checking if gcc supports -Wl,--as-needed flag... yes checking if gcc supports flag -Wall in envvar CFLAGS... yes checking if gcc supports flag -Wextra in envvar CFLAGS... yes checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile config.status: creating icons/Makefile config.status: creating packaging/tg-timer.spec config.status: executing depfiles commands

    Tg 0.6.1-tpiepho
    =====

    prefix:                 /ucrt64

    compiler:               gcc
    cflags:                 -g -O2
    ldflags:                 -Wl,--as-needed

    Python support:         yes
      Filter plot:          yes
      Spectrograms:         yes

Also for completion sake here is the error that occurs when the tg-timer.exe is run directly in the respective folder:

$ ./tg-timer.exe Could not find platform dependent libraries Traceback (most recent call last): File "C:/msys64/ucrt64/lib/python3.11/site-packages/numpy/core/init.py", line 24, in from . import multiarray File "C:/msys64/ucrt64/lib/python3.11/site-packages/numpy/core/multiarray.py", line 10, in from . import overrides File "C:/msys64/ucrt64/lib/python3.11/site-packages/numpy/core/overrides.py", line 8, in from numpy.core._multiarray_umath import ( ImportError: DLL load failed while importing _multiarray_umath: Imposs▒vel localizar o m▒dulo especificado.

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "C:/msys64/ucrt64/lib/python3.11/site-packages/numpy/init.py", line 130, in from numpy.config import show as show_config File "C:/msys64/ucrt64/lib/python3.11/site-packages/numpy/config.py", line 4, in from numpy.core._multiarray_umath import ( File "C:/msys64/ucrt64/lib/python3.11/site-packages/numpy/core/init.py", line 50, in raise ImportError(msg) ImportError:

IMPORTANT: PLEASE READ THIS FOR ADVICE ON HOW TO SOLVE THIS ISSUE!

Importing the numpy C-extensions failed. This error can happen for many reasons, often due to issues with your setup or how NumPy was installed.

We have compiled some common reasons and troubleshooting tips at:

https://numpy.org/devdocs/user/troubleshooting-importerror.html

Please note and check the following:

The Python version is: Python3.11 from "C:/msys64/home/Effgarces/tg/tg-timer.exe"
The NumPy version is: "1.26.4"

and make sure that they are the versions you expect. Please carefully study the documentation linked above for further help.

Original error was: DLL load failed while importing _multiarray_umath: Imposs▒vel localizar o m▒dulo especificado.

The above exception was the direct cause of the following exception:

Traceback (most recent call last): File "C:/msys64/ucrt64/lib/python3.11/site-packages/numpy/init.py", line 135, in raise ImportError(msg) from e ImportError: Error importing numpy: you should not try to import numpy from its source directory; please exit the numpy source tree, and relaunch your python interpreter from there.

Did some searching about this. Maybe people talking about adding the directory the libraries are in to PATH, but usually this seems to be when installed by Anaconda, which apparently needs this.

Something to try would be execute: python -c "import numpy; print(numpy.pi)" in the same shell that tg-timer does not run from. If that works, then probably the PATH is fine.

That leads to bugs like https://bugs.python.org/issue36716 and https://github.com/numpy/numpy/issues/25888 In these bugs, python standalone works, but when embedded in an app, it can not find numpy libraries.

The root cause in one of them was running the embedded python in debug mode. Which I don't think I'm doing. But I have a test. Try this command from the shell: python -c "import importlib.machinery;print(importlib.machinery.all_suffixes())"

Then try the latest version of test branch I linked to before. It should print out the same list of suffixes when the signal dialog is opened and python is initialized. If the list is different, that might be while it can not find the module.

The fact that moving the .exe to the bin folder makes it work properly makes me heavily lean in the direction of a missing path somewhere, but I think I've exhausted most of the paths that I could remember. Here is the result of the first test: $ python -c "import numpy; print(numpy.pi)" 3.141592653589793

And the test for the debug mode: $ python -c "import importlib.machinery;print(importlib.machinery.all_suffixes())" ['.py', '.pyw', '.pyc', '.cp311-mingw_x86_64_ucrt.pyd', '.pyd']

And finally the result from the .exe when python is initialized: $ ./tg-timer.exe Could not find platform dependent libraries <exec_prefix> ['.py', '.pyw', '.pyc', '.cp311-mingw_x86_64_ucrt.pyd', '.pyd']

I've packaged my wonky "working" solution together with a bat file to start tg-timer.exe over at \bin folder. This is just a test to see if works correctly on other machines, maybe someone else can check if it works for them. So basically one just needs to download the zip, extract it and run start-tg.bat inside the tg folder. https://github.com/effgarces/tg/releases/tag/v0.6.1-tpiepho

I've pushed some new stuff to the testing branch to try.

The python docs say setting the program name has something to do with configuring paths. Has no effect I can see in Linux, but maybe it matters for Windows.

I've also added code to print the python path when tg starts python. It would interesting to compare to the path when python is run:

python -c "import sys ; print(sys.path)"

This is the printed path by the executable: $ ./tg-timer.exe Could not find platform dependent libraries ['.py', '.pyw', '.pyc', '.cp311-mingw_x86_64_ucrt.pyd', '.pyd'] ['C:/msys64/ucrt64/lib/python311.zip', 'C:/msys64/ucrt64/lib/python3.11', 'D:/a/msys64/ucrt64/lib/python3.11/lib-dynload', 'C:/msys64/ucrt64/lib/python3.11/site-packages', 'C:/msys64/ucrt64/lib/python3.11/site-packages/libtfr-2.1.8-py3.11-mingw_x86_64_ucrt.egg']

And this the one printed by the code snippet ['', 'C:/msys64/ucrt64/lib/python311.zip', 'C:/msys64/ucrt64/lib/python3.11', 'C:/msys64/ucrt64/lib/python3.11/lib-dynload', 'C:/msys64/ucrt64/lib/python3.11/site-packages', 'C:/msys64/ucrt64/lib/python3.11/site-packages/libtfr-2.1.8-py3.11-mingw_x86_64_ucrt.egg']

xyzzy42 / tg

Windows version compile instructions #8