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 <[email protected]> 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, [email protected] 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 <[email protected]> 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, [email protected] 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 <[email protected]> wrote: > > Hi enztec, > > thanks, fixed in SVN 1650. > > Best Regards, > Jürgen > > > On 2/25/23 1:01 AM, [email protected] 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); > > > > > > >
