Deprecated use of Py_Initialize in gdlpython.cpp
Hi All,
the latest Windows build in GitHub actions gives the following error (which is actually Python-specific):
In file included from D:/a/gdl/gdl/src/datatypes.cpp:48:
D:/a/gdl/gdl/src/gdlpython.cpp: In function 'std::nullptr_t PythonInit()':
D:/a/gdl/gdl/src/gdlpython.cpp:57:16: warning: 'void PySys_SetArgv(int, wchar_t**)' is deprecated [-Wdeprecated-declarations]
57 | PySys_SetArgv(argc, argv);
| ~~~~~~~~~~~~~^~~~~~~~~~~~
In file included from C:/hostedtoolcache/windows/Python/3.11.3/x64/include/Python.h:96,
from D:/a/gdl/gdl/src/typedefs.hpp:52,
from D:/a/gdl/gdl/src/datatypes.hpp:23,
from D:/a/gdl/gdl/src/datatypes.cpp:25:
C:/hostedtoolcache/windows/Python/3.11.3/x64/include/sysmodule.h:13:38: note: declared here
13 | Py_DEPRECATED(3.11) PyAPI_FUNC(void) PySys_SetArgv(int, wchar_t **);
| ^~~~~~~~~~~~~
D:/a/gdl/gdl/src/gdlpython.cpp: In function 'BaseGDL* lib::gdlpython(EnvT*, int)':
D:/a/gdl/gdl/src/gdlpython.cpp:215:22: warning: 'void PySys_SetArgv(int, wchar_t**)' is deprecated [-Wdeprecated-declarations]
215 | PySys_SetArgv(argc, argv);
| ~~~~~~~~~~~~~^~~~~~~~~~~~
C:/hostedtoolcache/windows/Python/3.11.3/x64/include/sysmodule.h:13:38: note: declared here
13 | Py_DEPRECATED(3.11) PyAPI_FUNC(void) PySys_SetArgv(int, wchar_t **);
| ^~~~~~~~~~~~~
I just checked the Python documentation and it seems, that starting from 3.11, the old init API is deprecated. The new (config) API is there from 3.8 and they want to support only the new one ([https://github.com/python/cpython/issues/88279](see the issue about this)). I found the following pages, which IMO can help:
- [https://docs.python.org/3/c-api/init.html#c.PySys_SetArgv](Python C API Reference - Initialization, Finalization, and Threads section)
- [https://docs.python.org/3/c-api/init_config.html#init-config](Python Initialization Configuration - The possible solution)
I also found a code segment on GitHub, which can help implement the new method: [https://github.com/RfidResearchGroup/proxmark3/pull/1833/files](code here).
Since I am not able to compile GDL right now, can anyone look into this? If you help me solve my compiling issues, I can also look into this, gladly.
Cheers, Csega
Thanks @Csega So it would seem more profitable that , I quote, "[somebody] help me solve my compiling issues" :smile: Could you be more specific about those compiling issues, since we do not see much compiling issues nowadays (not that we love to see them, actually, but...)
Hi @GillesDuvert,
thanks for the quick response!
Maybe it is trivial, but my working config just stopped compiling GDL once with the following (linking) error:
/usr/bin/ld: CMakeFiles/gdl.dir/hdf5_fun.cpp.o: undefined reference to symbol 'H5Tget_array_dims2@@HDF5_SERIAL_1.8.7'
/usr/bin/ld: /lib/x86_64-linux-gnu/libhdf5_serial.so.103: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [src/CMakeFiles/gdl.dir/build.make:2663: src/gdl] Error 1
make[1]: *** [CMakeFiles/Makefile2:216: src/CMakeFiles/gdl.dir/all] Error 2
make: *** [Makefile:146: all] Error 2
I tried to Google it, but could not find anything useful. Could you help me please figure out, what's wrong with it? CMAKE finds HDF5 without any problems. I use Ubuntu 22.04.
However, I found one thing, which I don't understand. The error message says HDF5_SERIAL_1.8.7, but I have HDF5 1.10.7 installed (according to the h5cc -showconfig command).
Beats me, but I see https://linux.debian.user.narkive.com/nn2DnBNU/trilinos-build-from-source-code where it would seem the hdf5-dev is mandatory? Apparently our HDF5 specialist is @ogressel : https://github.com/gnudatalanguage/gdl/pulls?q=is%3Apr+is%3Aclosed+author%3Aogressel
I carefully check on my laptop (u22.04) which hdf5 we have when compiling with the script :
$ ldd ~/GDL/gdl-1.0.2git230518/install/bin/gdl
libhdf5_serial.so.103 => /lib/x86_64-linux-gnu/libhdf5_serial.so.103 (0x00007f261f400000)
libhdf5_serial_hl.so.100 => /lib/x86_64-linux-gnu/libhdf5_serial_hl.so.100 (0x00007f261e0d400)
Seems to be the same than you, and I do have python too ...
Hi, and apologies for the slow response. I recall having had an issue with CMake and HDF5 on my Ubuntu 20.04 at work. My workaround was to remove the 'QUIET' - find_package(HDF5 QUIET) + find_package(HDF5) No idea why that worked, but I also had a mixup between the serial build that came with Ubuntu and a MPI-parallel one that I compiled myself. Not an expert on CMake, but there is probably a way to deal with this in a more robust way.
If removing QUIET is confirmed, this is more than easily done and not harmful anyway.