Proper way to include non-extension library in wheel

[reverendbedford]

My project is structured to first build a common shared library containing the basic functionality (say libbasic.so) and then a series of extension modules (say module_a.cpython-xx-yy.so, module_b.cpython-xx-yy.so). The modules link to libbasic.so and I have the RUNPATH set so that when you build and install the source distribution the common library gets installed to the package folder and the modules all pickup the common library correctly.

How should I structure a project of this type to play nicely with cibuildwheel and auditwheel? If I don't change anything I get an error relating to the common library:

ValueError: Cannot repair wheel, because required library "libbasic.so" could not be located

I can get around this (at least on linux) by first compiling libbasic.so by itself, setting LD_LIBRARY_PATH to make it available to the linker, and then run the cibuildwheel process. But that seems inelegant.

I don't think this is a bug at all, just wonder how to structure this type of package. Thanks!

[Kin-Zhang]

I also have this problem, without cibuildwheel in gtihub action, but new environment to build from source is fine, and inside .whl like unzip -l I also saw the .so

   209832  2023-11-28 16:30   lib/libglog.so
   209832  2023-11-28 16:30   lib/libglog.so.0.6.0
   209832  2023-11-28 16:30   lib/libglog.so.1
   384936  2023-11-28 16:30   lib/libtbb.so
   659788  2023-11-28 16:30   lib/libtbb_static.a
   191168  2023-11-28 16:30   lib/libtbbmalloc.so

However, when I use github action with cibuildwheel, we can build wheel successfully but repair failed.

Building wheel...
                                                            ✓ 208.97s
Repairing wheel...
                                                              ✕ 1.65s

because of:

ValueError: Cannot repair wheel, because required library "libglog.so.1" could not be located