[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compiling libapl for python3
|
From: |
enztec |
|
Subject: |
Re: compiling libapl for python3 |
|
Date: |
Thu, 2 Mar 2023 14:10:34 -0700 |
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 <mail@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, enztec@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 <mail@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, enztec@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 <mail@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, enztec@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 <mail@xn--jrgen-sauermann-zvb.de> wrote:
>
> Hi enztec,
>
> thanks, fixed in SVN 1650.
>
> Best Regards,
> Jürgen
>
>
> On 2/25/23 1:01 AM, enztec@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);
>
>
>
>
>
>
>
>
>