Hi Jürgen, your analysis was good - thanks
i checked my notes more closely and i had indeed compiled the python3.10.7 with gcc-6.3.0 and that is why compiling the python3 libapl for lib_gnu_apl.so with gcc-6.3.0 gave a good library. you have -fstack-protector in the src/Makefile so if i use CXXFLAGS="-fno-stack-protector" in my configure line with gcc-12.2.0 i now get a good lib_gnu_apl.so btw i don't get any programs from any distro - i have a pure source linux 64bit installation - and it isn't lfs/blfs based and no debs or rpms installed your analysis on this from svn 1648 to svn 1651 has been much appreciation enztec On Thu, 2 Mar 2023 10:14:42 +0100 Dr. Jürgen Sauermann <m...@xn--jrgen-sauermann-zvb.de> wrote: > Hi enztec, > > 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); > > > > > > > > >
