I am using:
eedjsa@server68:~/apl-1.8/src$ g++ --version
g++ (Ubuntu 9.4.0-1ubuntu1~18.04) 9.4.0
eedjsa@server68:~/apl-1.8/src$ python --version
Python 3.8.0
Your problem below indicates that there is some mismatch between
your python compilation (or compiler flags) and the compilation of lib_gnu_apl.so .
You need to ensure that Python and APL are compiled in the same fashion.
Usually the Python version that comes with your GNU/Linux distribution works
fine, but if you re-install Python in a binary format then you may run into
this kind of problems because the symbols used resp. provided by different
compile environments don't match.
BTW: the command
nm -D <filename> | grep <symbolname>
is the tool to troubleshoot such problems. The symbol __stack_chk_guard
very much looks like a symbol needed by your compiler (-version) and there
is little that GNU APL can do about it.
Maybe compiler flag -fstack-check when compiling APL helps.
Best Regards,
Jürgen
On 3/1/23 11:14 PM, enz...@gmx.com
wrote:
Hi Jürgen, I now get :import gnu_apl ImportError: /usr/local/lib/python3.10/lib-dynload/gnu_apl.cpython-310-x86_64-linux-gnu.so: undefined symbol: __stack_chk_guard i had upgraded gcc-6.3.0 to gcc-12.2.0 after my original compiling of svn 1553 if i recompile svn 1553 with the current gcc-12.2.0 i get the same above error (but recompiling with gcc-6.3.0 gives a good lib_gnu_apl.so) if i recompile svn 1651 with gcc-6.3.0 i get a good python3 lib_gnu_apl.so what gcc version are you using ? and what python3.10 version? enztec On Wed, 1 Mar 2023 16:17:43 +0100 Dr. Jürgen Sauermann <m...@xn--jrgen-gcc-12.2.0sauermann-zvb.de> wrote:Hi again, I believe that I have found the problem. main() was indeed referenced from APL (in Backtrace.cc) and apparently Python 3.10 has become more picky about undefined symbols in shared libraries than e.g. 3.8. As a matter of fact, main() has been undefined all the time (without any harm), but now Python 3.10 complains about this. Fixed in SVN 1651. Best Regards, Jürgen On 3/1/23 3:37 PM, Dr. Jürgen Sauermann wrote: Hi enztec, The error message that you are getting is rather strange since the .so file is not supposed to contain a main symbol (and the python API for 3.10 looks the same as for 3.8. And none of the other python .so libraries has a symbol 'main'. Maybe you need a 'make clean' in the GNU APL top-level directory before compiling for python (in case main is referenced from a stale APL source rather than from python). Best Regards, Jürgen On 2/28/23 8:11 PM, enz...@gmx.com wrote: Hi Jürgen I'm using Python 3.10.7 for both and the svn it works with is 1533 and with svn 1650 'import gnu_apl' gives the 'main' error both of the compiled /usr/local/lib/apl/lib_gnu_apl.so are copied to /usr/local/lib/python3.10/lib-dynload/gnu_apl.cpython-310-x86_64-linux-gnu.so i didn't change or add anything in regards to the python3.10.7 installation from svn 1533 to svn 1650 if i copy the 1533 compiled lib_gnu_apl.so back to /usr/local/lib/python3.10/lib-dynload/gnu_apl.cpython-310-x86_64-linux-gnu.so the main error goes away with 'import gnu_apl' and my python3 libapl code works perfectly don't worry about it - i was just upgrading to 1648 and have some tests i run on a new svn installation - i don't do anything with python3 anyway and my apl ws and apl scripting code and libapl fpc code all runs fine enztec On Tue, 28 Feb 2023 12:01:59 +0100 Dr. Jürgen Sauermann <m...@xn--jrgen-sauermann-zvb.de> wrote: Hi enztec, which SVN version worked on your side? And does it still work? I suppose that the python callling conventions for modules have changed in the meantime, since there never was a main() function in python_apl.cc. Best Regards, Jürgen On 2/27/23 10:35 PM, enz...@gmx.com wrote: Hi Jürgen import gnu_apl Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: /usr/local/lib/python3.10/lib-dynload/gnu_apl.cpython-310-x86_64-linux-gnu.so: undefined symbol: main a gnu_apl.so from an earlier svn compile works fine - so nothing has changed at this end thanks On Sun, 26 Feb 2023 18:18:27 +0100 Dr. Jürgen Sauermann <m...@xn--jrgen-sauermann-zvb.de> wrote: Hi enztec, thanks, fixed in SVN 1650. Best Regards, Jürgen On 2/25/23 1:01 AM, enz...@gmx.com wrote: when compiling libapl for python3 i get following make problem python_apl.cc: In function 'PyObject* apl_exec(PyObject*, PyObject*)': python_apl.cc:198:64: error: no matching function for call to 'Workspace::SI_top_error()' 198 | if (const StateIndicator * si = Workspace::SI_top_error()) | ~~~~~~~~~~~~~~~~~~~~~~~^~ In file included from python_apl.cc:15: Workspace.hh:212:28: note: candidate: 'static StateIndicator* Workspace::SI_top_error(bool)' 212 | static StateIndicator * SI_top_error(bool quad_LRX);
