Missing Library when Importing Python Module

Coreform Cubit
#1

Coreform Cubit Version: 2021.11
Platform: CentOS Linux 7

Hi all, I’m currently trying to import the Python Cubit module in order to do some Python manipulation and am running into an issue with a missing library. When importing the module I get the following error:

Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/kendwill/Coreform-Cubit-2021.11/bin/cubit.py", line 32, in <module> from cubit3 import * File "/home/kendwill/Coreform-Cubit-2021.11/bin/cubit3.py", line 15, in <module> import _cubit3 ImportError: libsec.so.0: cannot open shared object file: No such file or directory

Running ldd on _cubit3.so reveals that I am indeed missing libsec.so.0. Unfortunately, my searches of the internet show almost zero reference to this missing library. I found a reference here indicating that it might be a part of some Solaris libraries (not that I know what those are). Any ideas from y’all as to where I can get a hold of this library, or if it’s an indication I’m missing something else? I’d be happy to elaborate if there’s more information I can share.

Note: I run ldd on the same file on my personal Ubuntu18 laptop and a separate cluster running CentOS7, and neither shows libsec.so.0 as a required library.

#2

That’s…very odd. The library isn’t changing across your systems, and these are the libraries that _cubit3.so is directly linked against (obtained with readelf -d _cubit3.so):
libpython3.8.so.1.0
lilbcubiti19.so
libcubit_util.so
libpthread.so.0
libstdc++.so.6
libm.so.6
libgcc_s.so.1
libc.so.6

I’ve never heard of libsec.so.0 either, and I’m pretty sure that we’re not shipping that or linking against it. Odds are it’s getting pulled in from something you have installed on your first system.

There’s a few things you can try:

  1. First make sure that you’re using the Python3 that ships with Cubit, at /home/kendwill/Coreform-Cubit-2021.11/bin/python3/python3
  2. You can get a better sense of the include chain by using a tool like lddtree (available from yum install pax-utils)
  3. Look at your PATH and LD_LIBRARY_PATH environment variables and see if any of the directories in them have a libsec.so.0
  4. Take a system call log by running strace -o debug_libsec.txt python3 your_python_script.py and attaching the generated debug_libsec.txt here. We’ll try to diagnose the issue from there.
#3

Here’s the output from strace, I can’t quite tell what’s the originator of the call for libsec, hopefully you can. Running with the included python has the same error. I’ll get lddtree and reply with the output results from that in a little bit. Thanks Scot!

debug_libsec_2.txt (398.2 KB)

#4

Very odd, I ran lddtree and the output never even mentions libsec.so.0.
lddtree_output.txt (16.0 KB)

#5

Maybe it’s coming from libudev and/or libnuma? Those are in your /usr/lib64 directory and right after that we’re trying to load libsec. None of those show up in your lddtree output either. I think this means you’ve got something funky going on with Python. Do you have any environment variables set for Python like PYTHONHOME?

#6

Hi all, I managed to circumvent this error simply by unloading a module I had loaded, specifically OpenMP. I’m guessing somewhere in the chain of dependencies something got thrown off by OpenMP’s inclusion!