Dependency Hell

#1

Hi All

This is a bit of a head scratcher, I’ve got a python class that does some generation and markup, which ultimately constructs an exodus mesh. The underlying geometry is parametrically instanciated, and is called by another python script. If I were to want to run this python script that interfaces directly with Cubit, I would need to do the following

LD_LIBRARY_PATH=/path/to/cubit/bin:/path/to/cubit/bin/python3 PYTHONPATH=/path/to/cubit/bin myscript.py

I can remove the need for PYTHONPATH by setting it internal to the script and then all is well.

Now, my driving script is part of another framework, with a complex dependency stack managed mostly by pip, but does include system packages, most notably, requiring standard C++ libraries. When I set the LD_LIBRARY_PATH with Cubit dependencies in higher order, then Cubit runs fine, however when I run with Cubit dependencies in the opposing order, i.e. in the order required for my other dependencies to call my other parts of the program, then cubit doesnt run because of symbol mismatces.

I feel that maybe this could be fixed by setting the RPATH on the various parts of the budled libraries in Cubit, or is there any other advice?

#2

Hi @makeclean, if you look with readelf you’ll see that the most libraries already have a relative rpath set to the bin directory. If you manually set all the rpaths to the absolute path with patchelf, that should have the same effect as LD_LIBRARY_PATH. You can do that with a Python script that iterates over the directory, uses lief to determine if the file is an ELF file, then calls patchelf to set the rpath to the appropriate absolute path.

Keep in mind if you relocate the Cubit installation somewhere after setting absolute rpaths, it’ll cease to work.