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 CX
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 t
> 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_gn
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.
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 fa
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 'mai
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 ch
Hi again,
just tried python 3.8 and everything works just fine.
The README-10-python is slightlly out of date since it says to
copy
the GNU APL .so file into /usr/lib/python3.4/lib-dynload/.
This was
apparently correct at the time of writ
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 Regar
Hi Jürgen
>>> import gnu_apl
Traceback (most recent call last):
File "", line 1, in
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
th
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(PyObje
11 matches
Mail list logo
