Symbols not found

[alecandido]

Ok, this might really be the wrong place to open this issue. But if this is the case, I'm just asking for proper redirection to people that have a better understanding.

My problem is made of two main constituents:

• I want to ship a compiled CLI in a Python package, and
• this CLI depend on a shared object (dynamic library, as you prefer)

Well, a few more extra details are that the CLI is written in Rust, depending on a C++ library, and I'm using maturin with bin bindings to package everything.
I believe this information to be irrelevant: at the end of the day, auditwheel is run, and I'm left with a wheel containing three folders:

1. metadata in mypackage-x.y.z.dist-info (irrelevant)
2. the binary in mypackage-x.y.z.data/scripts
3. the shared object in mypackage.libs

The package is already on PyPI, just in case someone wants to experiment. And there is a single wheel.

Now the problem: when I run pip install mypackage, the two folders with data and dist-info are copied inside env/lib/python3.x/site-packages, while the binary inside the data/scripts folder is directly copied in env/bin.

When I run it locally, everything works (this corresponds to run maturin develop). When I run it after pip install, it cries for missing symbols.
But if I check with strings or nm inside the shared object in mypackage.libs, the symbol is there.

I have not been able to make it work, not even changing LD_LIBRARY_PATH or RPATH env vars.

Any idea?

[alecandido]

Ok, now I have been able: if I point LD_LIBRARY_PATH to the env/lib/python3.x/site-packages/mypackage.libs/ (i.e. I prepend it in the list), and I change the name of the library (i.e. I added a link to it), then it is working.

The problem is that the library that is shipped, is weirdly mangled from libMyPackage.so to libMyPackage-9066515f.so (where 9066515f is likely to be an hash, or something similar), and the linker is then not founding it.

But in any case, it would not be able to load, because even if the name were not mangled (that I tried by linking), the folder would not be searched by the linker. Nor any other symbolic link to a searched place (if there is any out of LD_LIBRARY_PATH) is created.

How is it supposed to work?
The wheel is compiled like this by auditwheel, I guess, unless maturin is doing something more... And for sure wheelname.libs is created by auditwheel, because it corresponds to #90, so why is it created, if it is not used later?

[mayeut]

duplicates #340

auditwheel does not support repairing binaries in scripts when they have dependencies. If you wanna publish a binary cli app, then it has to go in platlib (as if you were doing a library rather than an app) and you have to provide a wrapper script in scripts that calls your binary cli app.