undefined symbol: _Z26cheminformatics_types_initv

[abunaser69]

Hi,

When I ran intro_example.py I got the following error:

ImportError Traceback (most recent call last)
Cell In[39], line 15
12 from opencog.type_constructors import *
14 # Import all of the chemical element types, and bond types too.
---> 15 from opencog.cheminformatics import *
17 # Nothing works without a default AtomSpace, so create that first.
18 spa = AtomSpace()

ImportError: /home/naser/anaconda3/envs/pymc_env/lib/python3.12/site-packages/opencog/cheminformatics.so: undefined symbol: _Z26cheminformatics_types_initv

Your help would be much appreciated.

[linas]

Argh. Works fine for me. I get the below.

$ python3 ./intro_example.py
Hello! The AtomSpace is <AtomSpace
   addr: 0x32935830
   name: (uuid . 1)>

The Helium atom is (He "foo")
The CH bond is (SB
  (C "some carbon atom")
  (H "just a proton, ok?"))
Methane is a molecule: (Molecule
  (SB
    (C "1")
    (H "2"))
  (SB
    (C "1")
    (H "4"))
  (SB
    (C "1")
    (H "1"))
  (SB
    (C "1")
    (H "3")))

So we have to debug your system. Looks to me like you are running python virtualenv ... In my personal experience, venv exhibits a rich and glorious rainbow of strange, unusual, hard-to-debug, hard-to-work-around bugs that elevates the thrill of programming to the center spotlight.

If possible, just don't use venv. If that's not possible... can you change yourPYTHONPATH to include /usr/local/lib/python3.11/dist-packages/ (or 3.12 in your case)?

The message undefined symbol: _Z26cheminformatics_types_initv says that the shared library loader for python venv cannot find this symbol, which is contained in a different library.

Where? For me, I see this:

ldd -r /usr/local/lib/python3.11/dist-packages/opencog/cheminformatics.so
	linux-vdso.so.1 (0x00007fff705cc000)
	libcheminformatics-types.so => /usr/local/lib/opencog/libcheminformatics-types.so (0x00007f9929208000)
	libpython3.11.so.1.0 => /lib/x86_64-linux-gnu/libpython3.11.so.1.0 (0x00007f9928a00000)
	libcogutil.so => /usr/local/lib/opencog/libcogutil.so (0x00007f99289a0000)
... lots more... 
	libatom_types.so => /usr/local/lib/opencog/libatom_types.so (0x00007f9928850000)
	libatombase.so => /usr/local/lib/opencog/libatombase.so (0x00007f99283e0000)
	libatomspace.so => /usr/local/lib/opencog/libatomspace.so (0x00007f9928820000)
... more...

and the missing symbol is in libcheminformatics-types.so (which I'm just guessing, but can be double-checked with

nm  /usr/local/lib/opencog/libcheminformatics-types.so

So if setting PYTHON_PATH doesn't cure it, try setting LD_LIBRARY_PATH to include /usr/local/lib/opencog/

Example:

LD_LIBRARY_PATH=/usr/local/lib/opencog/ python3 intro_example.py

Normally, these paths are set up by the make install step, but python virtualenv ignores/over-rides such configuration and replaces it with it's own thing, which, of course, doesn't work.

If you stumble across the 'one weird trick' that can solve this, please open a pull request to revise the python documentation, or set whatever additional flags are needed on install, or .. whatever..

[linas]

Post-script: I just now noticed a slight subtle difference between your error message, and what I have. I have this:

  $ nm /usr/local/lib/python3.11/dist-packages/opencog/cheminformatics.so |grep cheminformatics_types_init
                 U cheminformatics_types_init

The U means "undefined" The definition is found here:

     $ nm  /usr/local/lib/opencog/libcheminformatics-types.so |grep cheminformatics_types_init
0000000000003a80 T cheminformatics_types_init

The T says the symbol is defined in the text section.

But your error message is about _Z26cheminformatics_types_initv which is a C++ mangled variant on that name. This is somehow weirdly, strangely wrong, since the cheminformatics_types_init function is explicitly declared to be C and not C++, and it is a shared-library constructor function: it runs when the shared library ctors run, before python main runs. I don't like this; the name should not have been C++-mangled.

It's possible that this is the root cause of the bug. I'm guessing that maybe you ran cmake inside the python venv, and the python venv changed how cmake works? (or how gcc works, by giving it extra flags?) I had another venv user report bizarro cmake bugs (unrelated to opencog) that makes me think that venv is doing strange things with the build system.

Shared library ctors are little snippets of code that run before the C/C++ main() runs; they are loaded and executed by the linker/loader (usually gnu ld but there are others). It's possible that python venv tries to do something unusual, here. This is one reason why it would be hard to debug. But this is .. just a guess.

[abunaser69]

Hi Linas, This time I have avoided using the conda environment. Now I am getting a new error message: Scanning dependencies of target PythonEval [ 91%] Building CXX object opencog/cython/CMakeFiles/PythonEval.dir/PythonEval.cc.o /home/naser/soft2/opencog_repos/atomspace/opencog/cython/PythonEval.cc: In member function ‘std::string opencog::PythonEval::build_python_error_message(const string&)’: /home/naser/soft2/opencog_repos/atomspace/opencog/cython/PythonEval.cc:1139:17: error: ‘PyFrame_GetCode’ was not declared in this scope 1139 | PyFrame_GetCode(pyTracebackObject->tb_frame)->co_filename); | ^~~~~~~~~~~~~~~ make[2]: *** [opencog/cython/CMakeFiles/PythonEval.dir/build.make:63: opencog/cython/CMakeFiles/PythonEval.dir/PythonEval.cc.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:2937: opencog/cython/CMakeFiles/PythonEval.dir/all] Error 2 make: *** [Makefile:152: all] Error 2 Please let me know if you have any suggestions for resolving this issue. Kind regards, Abu

…

On Mon, 3 Feb 2025 at 18:24, Linas Vepštas ***@***.***> wrote: Post-script: I just now noticed a slight subtle difference btween your error message, and what I have. I have this: $ nm /usr/local/lib/python3.11/dist-packages/opencog/cheminformatics.so |grep cheminformatics_types_init U cheminformatics_types_init The U means "undefined: The definition is found here: $ nm /usr/local/lib/opencog/libcheminformatics-types.so |grep cheminformatics_types_init 0000000000003a80 T cheminformatics_types_init The T says the symbol is defined in the text section. But your error message is about _Z26cheminformatics_types_initv which is a C++ mangled variant on that name. This is someohow weirdly, strangely wrong, since the cheminformatics_types_init function is explicitly declared to be C and not C++, and it is a shared-library constructor function: it runs when the shared library ctors run, *before* python main runs. I don't like this; the name should not have been C++-mangled. It's possible that this is the root cause of the bug. I'm guessing that maybe you ran cmake inside the python venv, and the python venv changed how cmake works? (or how gcc works, by giving it extra flags?) I had another venv user report bizarro cmake bugs (unrelated to opencog) that makes me think that venv is doing strange things with the build system. Shared library ctors are little snippets of code that run *before* the C/C++ main() runs; they are loaded and executed by the linker/loader (usually gnu ld but there are others). It's possible that python venv tries to do something unusual, here. This is one reason why it would be hard to debug. But this is .. just a guess. — Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHOUKFJXA32BDIKNNS42XNL2N6X6BAVCNFSM6AAAAABWKSWZ72VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMZRG42DKOJXGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[linas]

After moving out of the "conda environment", you would need to rm -r build; mkdir build; cd build; cmake ..; make all over again, as otherwise, there's stuff with conda-things in your build directory, that no longer hold when conda is not there.

For general reference, you should document what "the conda environment" is. I cannot attempt to reproduce your issues without explicit detailed descriptions of what you are doing that creates these issues.