The manylinux Python 2.7 wheel includes unnecessary/broken .sos (ortools-6.10.6025-cp27-cp27m-manylinux1_x86_64.whl)

[thehcma]

After downloading ortools-6.10.6025-cp27-cp27m-manylinux1_x86_64.whl I noticed that two libraries that are being distributed are both broken (as well as, unnecessary in that form, in my personal view) since they are not being used anywhere (unless, of course, they will be symlinked as is tradition in unixworld - more on that below):

$ ldd libCoinUtils.so
Inconsistency detected by ld.so: dl-version.c: 224: _dl_check_map_versions: Assertion `needed != NULL' failed!
$ ldd libCoinUtils.so.3.10.14:
Inconsistency detected by ld.so: dl-version.c: 224: _dl_check_map_versions: Assertion `needed != NULL' failed!

How come this is failing? Well, readelf shows us that they are actually broken:

$ readelf -d libCoinUtils.so

Dynamic section at offset 0x184000 contains 31 entries:
  Tag        Type                         Name/Value
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN/.]
 0x0000000600000001 (<unknown>: 600000001) 0x16e000
 0x000000000034b000 (<unknown>: 34b000)  0x34b000
 0x0000000000015608 (<unknown>: 15608)   0x15608
 0x0000000000001000 (<unknown>: 1000)    0x11f79

As can be seen above, neither can be correctly read by ELF-processing tools.

Upon further inspection, the native Python modules using libCoinUtils point directly to libCbc.so.3 (which is sane). See below:

$ readelf -d <blah>/python2.7/site-packages/ortools/algorithms/_pywrapknapsack_solver.so

Dynamic section at offset 0xf040 contains 43 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libgflags.so.2.2]
 0x0000000000000001 (NEEDED)             Shared library: [libglog.so.0.3.5]
 0x0000000000000001 (NEEDED)             Shared library: [libprotobuf.so.3.6.1]
 0x0000000000000001 (NEEDED)             Shared library: [libCbcSolver.so.3]
...
0x0000000000000001 (NEEDED)             Shared library: [libCoinUtils.so.3]
...

It seems to me, after looking at the source code distribution (e.g., or-tools_ubuntu-18.04_v6.10.6025.tar.gz on github):

lrwxrwxrwx 1 hcma hcma   23 2018-11-27 10:13:26.000000000 -0500 libCoinUtils.so -> libCoinUtils.so.3.10.14
lrwxrwxrwx 1 hcma hcma   23 2018-11-27 10:13:26.000000000 -0500 libCoinUtils.so.3 -> libCoinUtils.so.3.10.14
-rwxr-xr-x 1 hcma hcma 1.5M 2018-11-27 10:13:26.000000000 -0500 libCoinUtils.so.3.10.14

that the intention was to distribute the versioned .so files as symlinks in the wheel, but that's not what we have.

[Mizux]

to copy lib we use https://github.com/google/or-tools/blob/76dd97b5272d7e90fd95dc774ac3e2152749683d/makefiles/Makefile.python.mk#L1016-L1022 to list lib in setup.py https://github.com/google/or-tools/blob/76dd97b5272d7e90fd95dc774ac3e2152749683d/makefiles/Makefile.python.mk#L880-L903

I agree, we could remove them from the python package, but it need extra works, not sure it worth it...

[Mizux]

Also notice, to build the manylinux package we use the manylinux1 docker and auditwheel repair on the wheel package... AFAIK it seems it's auditwheel repair which is reponsible for breaking .so,

if locally, I build a linux package for my debian like distro, symlink are replaced by hard copy but they are not broken...:

$ cd <OR_ROOT>
$ make python # using python3.5
...
$ make pypi_archive
...
$ ls -l temp_python3.5/ortools/ortools/.libs/libCoinUtils.so
lrwxrwxrwx 1 corentinl primarygroup 23 Dec 20 08:40 temp_python3.5/ortools/ortools/.libs/libCoinUtils.so -> libCoinUtils.so.3.10.14
$ cd temp_python3.5/ortools/dist
$ unzip ortools-7.0b6136-cp35-cp35m-linux_x86_64.whl
$ ls -lh ortools/.libs/libCoinUtils.so
-rwxr-xr-x 1 corentinl primarygroup 1.5M Dec 20 07:40 ortools/.libs/libCoinUtils.so
$ ldd ortools/.libs/libCoinUtils.so
    linux-vdso.so.1 (0x00007ffc73f9c000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1724cfb000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1724976000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1724672000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f17242d3000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f17240bb000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f1725268000)

[lperron]

So won't fix, especially since Python2.7 will be soon obsolete.