Re: compiling libapl for python3

[Dr . Jürgen Sauermann]

    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);