bug-apl
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: compiling libapl for python3

From: Dr . Jürgen Sauermann
Subject: Re: compiling libapl for python3
Date: Thu, 2 Mar 2023 10:14:42 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
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);
            
            
          
        
      
  



    

    

  
















reply via email to








[Prev in Thread]
Current Thread
[Next in Thread]