Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Double library references after auditwheel repair #60

Closed
estan opened this issue May 1, 2016 · 26 comments
Closed

Double library references after auditwheel repair #60

estan opened this issue May 1, 2016 · 26 comments
Labels

Comments

@estan
Copy link

estan commented May 1, 2016

Sorry if this is obvious, but I tried for fun to manually create an anylinux wheel for h5py from a shell inside the provided x64 Docker container. However, it seems the rpath fixup didn't go too well for libz:

After the fixed up wheel was installed:

[root@a6722ca968b0 h5py-master]# ldd /opt/_internal/cpython-3.4.4/lib/python3.4/site-packages/h5py/h5a.cpython-34m.so
        linux-vdso.so.1 =>  (0x00007ffe2095d000)
        libhdf5-eb619e28.so.100.0.0 => /opt/_internal/cpython-3.4.4/lib/python3.4/site-packages/h5py/.libs/libhdf5-eb619e28.so.100.0.0 (0x00007f3e80eb2000)
        libhdf5_hl-250248ee.so.100.0.0 => /opt/_internal/cpython-3.4.4/lib/python3.4/site-packages/h5py/.libs/libhdf5_hl-250248ee.so.100.0.0 (0x00007f3e80c89000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3e80a67000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f3e8070e000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f3e80504000)
        libz-a147dcb0.so.1.2.3 => not found
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f3e80300000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f3e8007c000)
        libz-a147dcb0.so.1.2.3 => /opt/_internal/cpython-3.4.4/lib/python3.4/site-packages/h5py/.libs/./libz-a147dcb0.so.1.2.3 (0x00007f3e7fe67000)
        /lib64/ld-linux-x86-64.so.2 (0x00005606a1cff000)

Notice the two references to libz-a147dcb0.so.1.2.3, one of them found, the other one not. Any idea what could have gone wrong, or how I can debug further? The bundling of libhdf5 seems to have worked fine.

@ogrisel
Copy link
Contributor

ogrisel commented May 9, 2016

Indeed this looks like a bug in auditwheel cc @rmcgibbo / @njsmith.

Can you please include the output of the auditwheel show and auditwheel repair command when run on the original linux_x86_64.whl file? If those output look normal we will have to start a pdb session to trace what going wrong when grafting libz and related libraries.

@ogrisel ogrisel added the bug label May 9, 2016
@estan
Copy link
Author

estan commented May 9, 2016

Bah, it seems I somehow managed to lose both the Docker image I was manually doing this in, and my notes on what I did (could be on my laptop at home). But I'll do it all again as soon as possible and provide you with the output.

@estan
Copy link
Author

estan commented May 9, 2016

Alright, I found my notes again and did the test again.

You can test on your side with docker build -t h5py-manylinux-test:latest . and this Dockerfile:

FROM quay.io/pypa/manylinux1_x86_64

RUN yum install -y zlib-devel

# Download and extract HDF5
WORKDIR /
RUN wget http://www.hdfgroup.org/ftp/HDF5/releases/hdf5-1.10/hdf5-1.10.0/src/hdf5-1.10.0.tar.bz2
RUN tar xvfj hdf5-1.10.0.tar.bz2

# Build and install HDF5
WORKDIR /hdf5-1.10.0
RUN ./configure --prefix=/hdf5 --enable-unsupported --enable-threadsafe
RUN make
RUN make install

# Download and extract h5py master
WORKDIR /
RUN curl -L -o master.zip https://github.com/h5py/h5py/archive/master.zip
RUN unzip master.zip

# Compile h5py wheel
WORKDIR /h5py-master
ENV HDF5_DIR=/hdf5
RUN /opt/python/cp34-cp34m/bin/pip wheel . -w wheelhouse/

# Look at the wheel
RUN auditwheel show wheelhouse/h5py-2.6.0-cp34-cp34m-linux_x86_64.whl

# Build manylinux wheel
RUN auditwheel repair wheelhouse/h5py-2.6.0-cp34-cp34m-linux_x86_64.whl -w wheelhouse/

# Look at the wheelhouse
RUN ls -l wheelhouse/

# Install manylinux wheel
RUN /opt/python/cp34-cp34m/bin/pip install h5py --no-index -f wheelhouse/

# Look at library references of installed h5a.cpython-34m.so
RUN ldd /opt/_internal/cpython-3.4.4/lib/python3.4/site-packages/h5py/h5a.cpython-34m.so

The relevant output from auditwheel show and auditwheel repair on the original wheel is:

Step 16 : RUN auditwheel show wheelhouse/h5py-2.6.0-cp34-cp34m-linux_x86_64.whl
 ---> Running in 1caef67b1f1c

h5py-2.6.0-cp34-cp34m-linux_x86_64.whl is consistent with the
following platform tag: "linux_x86_64".

The wheel references the following external versioned symbols in
system-provided shared libraries: GLIBC_2.2.5.

The following external shared libraries are required by the wheel:
{
    "libc.so.6": "/lib64/libc-2.5.so",
    "libdl.so.2": "/lib64/libdl-2.5.so",
    "libhdf5.so.100": "/hdf5/lib/libhdf5.so.100.0.0",
    "libhdf5_hl.so.100": "/hdf5/lib/libhdf5_hl.so.100.0.0",
    "libm.so.6": "/lib64/libm-2.5.so",
    "libpthread.so.0": "/lib64/libpthread-2.5.so",
    "librt.so.1": "/lib64/librt-2.5.so",
    "libz.so.1": "/lib64/libz.so.1.2.3"
}

In order to achieve the tag platform tag "manylinux1_x86_64" the
following shared library dependencies will need to be eliminated:

libhdf5.so.100, libhdf5_hl.so.100, libz.so.1
 ---> 81ebed4a416f
Removing intermediate container 1caef67b1f1c
Step 17 : RUN auditwheel repair wheelhouse/h5py-2.6.0-cp34-cp34m-linux_x86_64.whl -w wheelhouse/
 ---> Running in 9e0760bffefd
Repairing h5py-2.6.0-cp34-cp34m-linux_x86_64.whl
Grafting: /hdf5/lib/libhdf5.so.100.0.0 -> h5py/.libs/libhdf5-18711fcd.so.100.0.0
Grafting: /hdf5/lib/libhdf5_hl.so.100.0.0 -> h5py/.libs/libhdf5_hl-250248ee.so.100.0.0
Setting RPATH: h5py/.libs/libhdf5_hl-250248ee.so.100.0.0 to "$ORIGIN/."
Grafting: /lib64/libz.so.1.2.3 -> h5py/.libs/libz-a147dcb0.so.1.2.3
Setting RPATH: h5py/h5fd.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/_proxy.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5ds.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5o.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5s.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5g.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/_conv.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5l.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5ac.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5f.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/defs.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5z.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5i.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5t.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5p.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5d.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/_errors.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5a.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5r.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/utils.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/_objects.cpython-34m.so to "$ORIGIN/.libs"
Previous filename tags: linux_x86_64
New filename tags: manylinux1_x86_64
Previous WHEEL info tags: cp34-cp34m-linux_x86_64
New WHEEL info tags: cp34-cp34m-manylinux1_x86_64

Fixed-up wheel written to /h5py-master/wheelhouse/h5py-2.6.0-cp34-cp34m-manylinux1_x86_64.whl
 ---> 9c0bf9ca9dc3
Removing intermediate container 9e0760bffefd

The output looks okay to me, but I'm not sure what to look for
h5py-manylinux.zip

.

@estan
Copy link
Author

estan commented May 9, 2016

Or, looking closer, the problem is that RPATH is not set on libhdf5-18711fcd.so.100.0.0, which also has a dependency on libz:

[root@0126552e52ab h5py-master]# ldd /opt/_internal/cpython-3.4.4/lib/python3.4/site-packages/h5py/.libs/libhdf5-18711fcd.so.100.0.0 
        linux-vdso.so.1 =>  (0x00007ffc45bf1000)
        librt.so.1 => /lib64/librt.so.1 (0x00007fba5063f000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fba50422000)
        libz-a147dcb0.so.1.2.3 => not found
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fba5021e000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fba4ff9a000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fba4fc41000)
        /lib64/ld-linux-x86-64.so.2 (0x0000560bc6f9f000)
[root@0126552e52ab h5py-master]#

This is what led to libz-a147dcb0.so.1.2.3 showing up twice in the ldd output for h5a.cpython-34m.so above.

Any idea what might be special about libhdf5-18711fcd.so.100.0.0 which makes the RPATH fixup miss it?

@estan
Copy link
Author

estan commented May 9, 2016

I realize now that this may not be an auditwheel issue at all:

[root@0126552e52ab h5py-master]# /opt/_internal/cpython-3.5.1/bin/python
Python 3.5.1 (default, May  6 2016, 22:59:06) 
[GCC 4.8.2 20140120 (Red Hat 4.8.2-15)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from auditwheel.elfutils import elf_read_rpaths
>>> elf_read_rpaths('/hdf5/lib/libhdf5.so.100.0.0')
{'runpaths': [], 'rpaths': []}
>>> elf_read_rpaths('/hdf5/lib/libhdf5_hl.so.100.0.0')
{'runpaths': [], 'rpaths': ['/hdf5/lib']}
>>>

Unlike libhdf5_hl.so.100.0.0, it seems libhdf5.so.100.0.0 has no RPATH set to begin with :/

@estan
Copy link
Author

estan commented May 9, 2016

And confirmed also with readelf:

[root@0126552e52ab hdf5-1.10.0]# readelf -d /hdf5/lib/libhdf5.so.100.0.0 

Dynamic section at offset 0x384ac8 contains 30 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000e (SONAME)             Library soname: [libhdf5.so.100]
 0x000000000000000c (INIT)               0x3b908
 0x000000000000000d (FINI)               0x2fc7b8
 0x0000000000000019 (INIT_ARRAY)         0x57e000
 0x000000000000001b (INIT_ARRAYSZ)       8 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x57e008
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x1b8
 0x0000000000000005 (STRTAB)             0x17208
 0x0000000000000006 (SYMTAB)             0x5748
 0x000000000000000a (STRSZ)              53559 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000003 (PLTGOT)             0x5865b8
 0x0000000000000002 (PLTRELSZ)           36480 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x32a88
 0x0000000000000007 (RELA)               0x25b70
 0x0000000000000008 (RELASZ)             53016 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0x25ad0
 0x000000006fffffff (VERNEEDNUM)         4
 0x000000006ffffff0 (VERSYM)             0x24340
 0x000000006ffffff9 (RELACOUNT)          1249
 0x0000000000000000 (NULL)               0x0
[root@0126552e52ab hdf5-1.10.0]# readelf -d /hdf5/lib/libhdf5_hl.so.100.0.0 

Dynamic section at offset 0x20120 contains 32 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libhdf5.so.100]
 0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000e (SONAME)             Library soname: [libhdf5_hl.so.100]
 0x000000000000000f (RPATH)              Library rpath: [/hdf5/lib]
 0x000000000000000c (INIT)               0x5940
 0x000000000000000d (FINI)               0x19fe8
 0x0000000000000019 (INIT_ARRAY)         0x220100
 0x000000000000001b (INIT_ARRAYSZ)       8 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x220108
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x1b8
 0x0000000000000005 (STRTAB)             0x2900
 0x0000000000000006 (SYMTAB)             0x740
 0x000000000000000a (STRSZ)              5732 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000003 (PLTGOT)             0x2205c0
 0x0000000000000002 (PLTRELSZ)           3936 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x49e0
 0x0000000000000007 (RELA)               0x4278
 0x0000000000000008 (RELASZ)             1896 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0x4238
 0x000000006fffffff (VERNEEDNUM)         2
 0x000000006ffffff0 (VERSYM)             0x3f64
 0x000000006ffffff9 (RELACOUNT)          3
 0x0000000000000000 (NULL)               0x0
[root@0126552e52ab hdf5-1.10.0]#

So I guess I'll have to figure out why HDF5 sets RPATH on one of them but not the other.

@ogrisel
Copy link
Contributor

ogrisel commented May 9, 2016

So I guess I'll have to figure out why HDF5 sets RPATH on one of them but not the other.

I think this is just because libhdf5_hl.so.100.0.0 has a dependencies on libhdf5.so.100.0.0 but not the other-way around and both are installed in a specific prefix lib folder.

zlib on the other hand is installed in the standard /lib64/ folder and is a dependency of both libhdf5_hl.so.100.0.0 and libhdf5.so.100.0.0. I think such a repeated transitive dependency is confusing the auditwheel repair command.

@ogrisel
Copy link
Contributor

ogrisel commented May 9, 2016

Could you please include the output of readelf on /opt/_internal/cpython-3.4.4/lib/python3.4/site-packages/h5py/h5a.cpython-34m.so?

@estan
Copy link
Author

estan commented May 9, 2016

So I guess I'll have to figure out why HDF5 sets RPATH on one of them but not the other.

I think this is just because libhdf5_hl.so.100.0.0 has a dependencies on libhdf5.so.100.0.0 but not the other-way around and both are installed in a specific prefix lib folder.

Alright, but correct me if I'm wrong: The tool requires the library to have an RPATH to begin with in order to work? It can't add an RPATH from scratch? If so I think I must look into the build of HDF5, since at the moment it produces libhdf5_hl.so.100.0.0 with an RPATH set, and a libhdf5.so.100.0.0 with no RPATH set.

Here's the output of readelf on on /opt/_internal/cpython-3.4.4/lib/python3.4/site-packages/h5py/h5a.cpython-34m.so:

[root@0126552e52ab hdf5-1.10.0]# readelf -d /opt/_internal/cpython-3.4.4/lib/python3.4/site-packages/h5py/h5a.cpython-34m.so

Dynamic section at offset 0x18090 contains 28 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libhdf5-18711fcd.so.100.0.0]
 0x0000000000000001 (NEEDED)             Shared library: [libhdf5_hl-250248ee.so.100.0.0]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/.libs]
 0x000000000000000c (INIT)               0x34b8
 0x000000000000000d (FINI)               0x15558
 0x0000000000000019 (INIT_ARRAY)         0x218070
 0x000000000000001b (INIT_ARRAYSZ)       8 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x218078
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x1b8
 0x0000000000000005 (STRTAB)             0x21d1c0
 0x0000000000000006 (SYMTAB)             0x1f8
 0x000000000000000a (STRSZ)              1984 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000003 (PLTGOT)             0x218368
 0x0000000000000002 (PLTRELSZ)           1704 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x2e10
 0x0000000000000007 (RELA)               0x1448
 0x0000000000000008 (RELASZ)             6600 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0x1428
 0x000000006fffffff (VERNEEDNUM)         1
 0x000000006ffffff0 (VERSYM)             0x1356
 0x000000006ffffff9 (RELACOUNT)          248
 0x0000000000000000 (NULL)               0x0
[root@0126552e52ab hdf5-1.10.0]#

@estan
Copy link
Author

estan commented May 9, 2016

Or wait, now I think I see what you mean. So perhaps my problem could be worked around by install HDF5 to prefix /usr? I'll give it a try.

@estan
Copy link
Author

estan commented May 9, 2016

Okay, installing HDF5 to prefix /usr, neither of the two libs get an RPATH:

[root@0126552e52ab hdf5-1.10.0]# readelf -d /usr/lib/libhdf5.so.100.0.0 

Dynamic section at offset 0x384ac8 contains 30 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000e (SONAME)             Library soname: [libhdf5.so.100]
 0x000000000000000c (INIT)               0x3b908
 0x000000000000000d (FINI)               0x2fc7b8
 0x0000000000000019 (INIT_ARRAY)         0x57e000
 0x000000000000001b (INIT_ARRAYSZ)       8 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x57e008
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x1b8
 0x0000000000000005 (STRTAB)             0x17208
 0x0000000000000006 (SYMTAB)             0x5748
 0x000000000000000a (STRSZ)              53559 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000003 (PLTGOT)             0x5865b8
 0x0000000000000002 (PLTRELSZ)           36480 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x32a88
 0x0000000000000007 (RELA)               0x25b70
 0x0000000000000008 (RELASZ)             53016 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0x25ad0
 0x000000006fffffff (VERNEEDNUM)         4
 0x000000006ffffff0 (VERSYM)             0x24340
 0x000000006ffffff9 (RELACOUNT)          1249
 0x0000000000000000 (NULL)               0x0
[root@0126552e52ab hdf5-1.10.0]# readelf -d /usr/lib/libhdf5_hl.so.100.0.0 

Dynamic section at offset 0x20120 contains 31 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libhdf5.so.100]
 0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000e (SONAME)             Library soname: [libhdf5_hl.so.100]
 0x000000000000000c (INIT)               0x5938
 0x000000000000000d (FINI)               0x19fe8
 0x0000000000000019 (INIT_ARRAY)         0x220100
 0x000000000000001b (INIT_ARRAYSZ)       8 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x220108
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x1b8
 0x0000000000000005 (STRTAB)             0x2900
 0x0000000000000006 (SYMTAB)             0x740
 0x000000000000000a (STRSZ)              5722 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000003 (PLTGOT)             0x2205b0
 0x0000000000000002 (PLTRELSZ)           3936 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x49d8
 0x0000000000000007 (RELA)               0x4270
 0x0000000000000008 (RELASZ)             1896 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0x4230
 0x000000006fffffff (VERNEEDNUM)         2
 0x000000006ffffff0 (VERSYM)             0x3f5a
 0x000000006ffffff9 (RELACOUNT)          3
 0x0000000000000000 (NULL)               0x0

The repair command is now:

[root@0126552e52ab h5py-master]# auditwheel repair wheelhouse/h5py-2.6.0-cp34-cp34m-linux_x86_64.whl -w wheelhouse/
Repairing h5py-2.6.0-cp34-cp34m-linux_x86_64.whl
Grafting: /usr/lib/libhdf5.so.100.0.0 -> h5py/.libs/libhdf5-0d74a8aa.so.100.0.0
Grafting: /usr/lib/libhdf5_hl.so.100.0.0 -> h5py/.libs/libhdf5_hl-53e266bc.so.100.0.0
Grafting: /lib64/libz.so.1.2.3 -> h5py/.libs/libz-a147dcb0.so.1.2.3
Setting RPATH: h5py/h5p.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/defs.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5o.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5l.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5a.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5i.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5fd.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/_errors.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5d.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/_proxy.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5t.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5s.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5g.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/_conv.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5ac.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/_objects.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/utils.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5ds.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5r.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5f.cpython-34m.so to "$ORIGIN/.libs"
Setting RPATH: h5py/h5z.cpython-34m.so to "$ORIGIN/.libs"
Previous filename tags: linux_x86_64
New filename tags: manylinux1_x86_64
Previous WHEEL info tags: cp34-cp34m-linux_x86_64
New WHEEL info tags: cp34-cp34m-manylinux1_x86_64

Fixed-up wheel written to /h5py-master/wheelhouse/h5py-2.6.0-cp34-cp34m-manylinux1_x86_64.whl

And the result is that:

[root@0126552e52ab h5py-master]# ldd /opt/_internal/cpython-3.4.4/lib/python3.4/site-packages/h5py/h5a.cpython-34m.so
        linux-vdso.so.1 =>  (0x00007ffc4fd67000)
        libhdf5-0d74a8aa.so.100.0.0 => /opt/_internal/cpython-3.4.4/lib/python3.4/site-packages/h5py/.libs/libhdf5-0d74a8aa.so.100.0.0 (0x00007f5519a97000)
        libhdf5_hl-53e266bc.so.100.0.0 => /opt/_internal/cpython-3.4.4/lib/python3.4/site-packages/h5py/.libs/libhdf5_hl-53e266bc.so.100.0.0 (0x00007f551986e000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f551964c000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f55192f3000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f55190e9000)
        libz-a147dcb0.so.1.2.3 => not found
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f5518ee5000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f5518c61000)
        /lib64/ld-linux-x86-64.so.2 (0x000055ac5fd10000)
        libz-a147dcb0.so.1.2.3 => not found
[root@0126552e52ab h5py-master]#

Not quite sure where to go from here :/

@njsmith
Copy link
Member

njsmith commented May 9, 2016

No, it shouldn't matter whether a library already has an RPATH or not -- we should always be setting a RPATH. (Or really we should always be setting a RUNPATH, which is basically the same.)

Maybe this has something to do with auditwheel treating transitive dependencies differently from direct dependencies or .so files that are included in the library directly? Really I think we should just be copying in all transitive dependencies, and then setting RUNPATH on everything in the new wheel -- no point in trying to be clever about which things need RUNPATH and which don't.

@estan
Copy link
Author

estan commented May 9, 2016

Alright, I see. The logic in auditwheel right now, unless I'm mistaken, seems to be that it will only "patch" existing RPATHS / RUNPATHS:

https://github.com/pypa/auditwheel/blob/master/auditwheel/repair.py#L129

and then

https://github.com/pypa/auditwheel/blob/master/auditwheel/repair.py#L135-L139

I thought you could only modify an existing RPATH, not insert one, but it seems patchelf should be capable of that, so I'm not sure why the code is written as it is.

@rmcgibbo
Copy link
Member

Alright, I see. The logic in auditwheel right now, unless I'm mistaken, seems to be that it will only "patch" existing RPATHS / RUNPATHS:

If the library that's being grafted in doesn't contain an existing RPATH or RUNPATH, I don't think it needs to acquire one...

@estan
Copy link
Author

estan commented May 10, 2016

@rmcgibbo: Ah that makes sense, wasn't thinking straight yesterday.

But, do you have any idea why I end up with:

[root@0126552e52ab h5py-master]# ldd /opt/_internal/cpython-3.4.4/lib/python3.4/site-packages/h5py/.libs/libhdf5-0d74a8aa.so.100.0.0 
        linux-vdso.so.1 =>  (0x00007ffff87c0000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f0b42831000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0b42614000)
        libz-a147dcb0.so.1.2.3 => not found
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f0b42410000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f0b4218c000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f0b41e33000)
        /lib64/ld-linux-x86-64.so.2 (0x0000563121212000)
[root@0126552e52ab h5py-master]# ls -l /opt/_internal/cpython-3.4.4/lib/python3.4/site-packages/h5py/.libs
total 4332
-rwxr-xr-x 1 root root 4162352 May  9 13:28 libhdf5-0d74a8aa.so.100.0.0
-rwxr-xr-x 1 root root  178344 May  9 13:28 libhdf5_hl-53e266bc.so.100.0.0
-rwxr-xr-x 1 root root   87528 May  9 13:28 libz-a147dcb0.so.1.2.3
[root@0126552e52ab h5py-master]#

This was from my last test, from when HDF5 was installed to /usr and consequently none of its two libraries had RPATH set to begin with.

In the above situation, libz-a147dcb0.so.1.2.3 should be found right?

@estan
Copy link
Author

estan commented May 10, 2016

I just have to ask:

If the library that's being grafted in doesn't contain an existing RPATH or RUNPATH, I don't think it needs to acquire one...

If the wheel has a transient dependency on a library though, shouldn't RPATH then be set on the intermediate library, so that it can find its dependency in turn?

@estan
Copy link
Author

estan commented May 10, 2016

To clarify (sorry for the bad asciii art, on my phone now), I think I have the following situation:

h5py -> libhdf5 -> libz
|        ^         ^
v        |        /
libhdf5_hl-------/

Shouldn't libhdf5 and libhdf5_hl be given rpaths here for this to work, despite not having any to begin with, for their dependencies to be found?

@estan
Copy link
Author

estan commented May 10, 2016

That turned out horrible:

h5py -> libhdf5
h5py -> libhdf5_hl 
libhdf5 -> libz
libhdf5_hl -> libhdf5
libhdf5_hl -> libz

@rmcgibbo
Copy link
Member

Okay, I think I see the bug and how to fix it.

@estan
Copy link
Author

estan commented May 10, 2016

Great, I had a look at your fix. Did you test it with the above yet? I'm on the bus but can test in half an hour or so.

But looking at the change, isn't it still the case that it will only set rpath if there already is one? If so, I'm not sure it'll work still... But will test.

@rmcgibbo
Copy link
Member

Yea, I tested it on the h5py build and got it to import successfully after repair.

Sent from my iPhone

On May 10, 2016, at 12:28 PM, Elvis Stansvik notifications@github.com wrote:

Great, I had a look at your fix. Did you test it with the above yet? I'm on the bus but can test in half an hour or so.

But looking at the change, isn't it still the case that it will only set rpath if there already is one? If so, I'm not sure it'll work still... But will test.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

@estan
Copy link
Author

estan commented May 10, 2016

Ah, excellent, then it's just me misunderstanding. Many thanks!

@ehashman
Copy link
Member

Can you test to see if auditwheel 1.10.0rc1 fixes this?

@webknjaz
Copy link
Member

Hi, I think I've hit the same issue with current manylinux1 container with auditwheel==1.10.0.
I upgraded it to auditwheel==2.0.0 but the issue is still present:

==============
WHEEL ANALYSIS
==============

Analysing /io/dist/pygit2-0.27.4-cp27-cp27m-manylinux1_x86_64.whl...

pygit2-0.27.4-cp27-cp27m-manylinux1_x86_64.whl is consistent with the
following platform tag: "linux_x86_64".

The wheel references external versioned symbols in these system-
provided shared libraries: libc.so.6 with versions {'GLIBC_2.3',
'GLIBC_2.2.5', 'GLIBC_2.3.4', 'GLIBC_2.3.2', 'GLIBC_2.4'}, librt.so.1
with versions {'GLIBC_2.2.5'}, libdl.so.2 with versions
{'GLIBC_2.2.5'}, libpthread.so.0 with versions {'GLIBC_2.2.5',
'GLIBC_2.3.2'}

The following external shared libraries are required by the wheel:
{
    "libc.so.6": "/lib64/libc-2.5.so",
    "libcurl.so.4": "/usr/local/lib/libcurl.so.4.5.0",
    "libdl.so.2": "/lib64/libdl-2.5.so",
    "libpthread.so.0": "/lib64/libpthread-2.5.so",
    "librt.so.1": "/lib64/librt-2.5.so",
    "libssh2.so.1": "/usr/local/lib64/libssh2.so.1.0.1",
    "libz.so.1": "/lib64/libz.so.1.2.3"
}

In order to achieve the tag platform tag "manylinux2010_x86_64" the
following shared library dependencies will need to be eliminated:

libcurl.so.4, libssh2.so.1, libz.so.1

In order to achieve the tag platform tag "manylinux1_x86_64" the
following shared library dependencies will need to be eliminated:

libcurl.so.4, libssh2.so.1, libz.so.1
Unpacking to: /tmp/pygit2-manylinux1-build.dHVbt28669/cp27-cp27m-pygit2/pygit2-0.27.4
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp27-cp27m-pygit2/pygit2-0.27.4/pygit2/.libs/libcurl-e8503455.so.4.5.0'
        libz-a147dcb0.so.1.2.3 => not found
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp27-cp27m-pygit2/pygit2-0.27.4/pygit2/.libs/libgit2-e2c814dd.so.0.27.8'
        libcurl-e8503455.so.4.5.0 => not found
        libz-a147dcb0.so.1.2.3 => not found
        libssh2-1766d285.so.1.0.1 => not found
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp27-cp27m-pygit2/pygit2-0.27.4/pygit2/.libs/libssh2-1766d285.so.1.0.1'
        libz-a147dcb0.so.1.2.3 => not found
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp27-cp27m-pygit2/pygit2-0.27.4/pygit2/.libs/libz-a147dcb0.so.1.2.3'
Analysing /io/dist/pygit2-0.27.4-cp27-cp27mu-manylinux1_x86_64.whl...

pygit2-0.27.4-cp27-cp27mu-manylinux1_x86_64.whl is consistent with the
following platform tag: "linux_x86_64".

The wheel references external versioned symbols in these system-
provided shared libraries: libc.so.6 with versions {'GLIBC_2.3.2',
'GLIBC_2.3', 'GLIBC_2.3.4', 'GLIBC_2.2.5', 'GLIBC_2.4'}, librt.so.1
with versions {'GLIBC_2.2.5'}, libpthread.so.0 with versions
{'GLIBC_2.3.2', 'GLIBC_2.2.5'}, libdl.so.2 with versions
{'GLIBC_2.2.5'}

The following external shared libraries are required by the wheel:
{
    "libc.so.6": "/lib64/libc-2.5.so",
    "libcurl.so.4": "/usr/local/lib/libcurl.so.4.5.0",
    "libdl.so.2": "/lib64/libdl-2.5.so",
    "libpthread.so.0": "/lib64/libpthread-2.5.so",
    "librt.so.1": "/lib64/librt-2.5.so",
    "libssh2.so.1": "/usr/local/lib64/libssh2.so.1.0.1",
    "libz.so.1": "/lib64/libz.so.1.2.3"
}

In order to achieve the tag platform tag "manylinux2010_x86_64" the
following shared library dependencies will need to be eliminated:

libcurl.so.4, libssh2.so.1, libz.so.1

In order to achieve the tag platform tag "manylinux1_x86_64" the
following shared library dependencies will need to be eliminated:

libcurl.so.4, libssh2.so.1, libz.so.1
Unpacking to: /tmp/pygit2-manylinux1-build.dHVbt28669/cp27-cp27mu-pygit2/pygit2-0.27.4
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp27-cp27mu-pygit2/pygit2-0.27.4/pygit2/.libs/libcurl-e8503455.so.4.5.0'
        libz-a147dcb0.so.1.2.3 => not found
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp27-cp27mu-pygit2/pygit2-0.27.4/pygit2/.libs/libgit2-e2c814dd.so.0.27.8'
        libcurl-e8503455.so.4.5.0 => not found
        libz-a147dcb0.so.1.2.3 => not found
        libssh2-1766d285.so.1.0.1 => not found
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp27-cp27mu-pygit2/pygit2-0.27.4/pygit2/.libs/libssh2-1766d285.so.1.0.1'
        libz-a147dcb0.so.1.2.3 => not found
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp27-cp27mu-pygit2/pygit2-0.27.4/pygit2/.libs/libz-a147dcb0.so.1.2.3'
Analysing /io/dist/pygit2-0.27.4-cp34-cp34m-manylinux1_x86_64.whl...

pygit2-0.27.4-cp34-cp34m-manylinux1_x86_64.whl is consistent with the
following platform tag: "linux_x86_64".

The wheel references external versioned symbols in these system-
provided shared libraries: libc.so.6 with versions {'GLIBC_2.3.4',
'GLIBC_2.4', 'GLIBC_2.2.5', 'GLIBC_2.3', 'GLIBC_2.3.2'}, librt.so.1
with versions {'GLIBC_2.2.5'}, libdl.so.2 with versions
{'GLIBC_2.2.5'}, libpthread.so.0 with versions {'GLIBC_2.3.2',
'GLIBC_2.2.5'}

The following external shared libraries are required by the wheel:
{
    "libc.so.6": "/lib64/libc-2.5.so",
    "libcurl.so.4": "/usr/local/lib/libcurl.so.4.5.0",
    "libdl.so.2": "/lib64/libdl-2.5.so",
    "libpthread.so.0": "/lib64/libpthread-2.5.so",
    "librt.so.1": "/lib64/librt-2.5.so",
    "libssh2.so.1": "/usr/local/lib64/libssh2.so.1.0.1",
    "libz.so.1": "/lib64/libz.so.1.2.3"
}

In order to achieve the tag platform tag "manylinux2010_x86_64" the
following shared library dependencies will need to be eliminated:

libcurl.so.4, libssh2.so.1, libz.so.1

In order to achieve the tag platform tag "manylinux1_x86_64" the
following shared library dependencies will need to be eliminated:

libcurl.so.4, libssh2.so.1, libz.so.1
Unpacking to: /tmp/pygit2-manylinux1-build.dHVbt28669/cp34-cp34m-pygit2/pygit2-0.27.4
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp34-cp34m-pygit2/pygit2-0.27.4/pygit2/.libs/libcurl-e8503455.so.4.5.0'
        libz-a147dcb0.so.1.2.3 => not found
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp34-cp34m-pygit2/pygit2-0.27.4/pygit2/.libs/libgit2-e2c814dd.so.0.27.8'
        libcurl-e8503455.so.4.5.0 => not found
        libz-a147dcb0.so.1.2.3 => not found
        libssh2-1766d285.so.1.0.1 => not found
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp34-cp34m-pygit2/pygit2-0.27.4/pygit2/.libs/libssh2-1766d285.so.1.0.1'
        libz-a147dcb0.so.1.2.3 => not found
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp34-cp34m-pygit2/pygit2-0.27.4/pygit2/.libs/libz-a147dcb0.so.1.2.3'
Analysing /io/dist/pygit2-0.27.4-cp35-cp35m-manylinux1_x86_64.whl...

pygit2-0.27.4-cp35-cp35m-manylinux1_x86_64.whl is consistent with the
following platform tag: "linux_x86_64".

The wheel references external versioned symbols in these system-
provided shared libraries: libc.so.6 with versions {'GLIBC_2.4',
'GLIBC_2.3.4', 'GLIBC_2.3', 'GLIBC_2.3.2', 'GLIBC_2.2.5'}, librt.so.1
with versions {'GLIBC_2.2.5'}, libpthread.so.0 with versions
{'GLIBC_2.2.5', 'GLIBC_2.3.2'}, libdl.so.2 with versions
{'GLIBC_2.2.5'}

The following external shared libraries are required by the wheel:
{
    "libc.so.6": "/lib64/libc-2.5.so",
    "libcurl.so.4": "/usr/local/lib/libcurl.so.4.5.0",
    "libdl.so.2": "/lib64/libdl-2.5.so",
    "libpthread.so.0": "/lib64/libpthread-2.5.so",
    "librt.so.1": "/lib64/librt-2.5.so",
    "libssh2.so.1": "/usr/local/lib64/libssh2.so.1.0.1",
    "libz.so.1": "/lib64/libz.so.1.2.3"
}

In order to achieve the tag platform tag "manylinux2010_x86_64" the
following shared library dependencies will need to be eliminated:

libcurl.so.4, libssh2.so.1, libz.so.1

In order to achieve the tag platform tag "manylinux1_x86_64" the
following shared library dependencies will need to be eliminated:

libcurl.so.4, libssh2.so.1, libz.so.1
Unpacking to: /tmp/pygit2-manylinux1-build.dHVbt28669/cp35-cp35m-pygit2/pygit2-0.27.4
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp35-cp35m-pygit2/pygit2-0.27.4/pygit2/.libs/libcurl-e8503455.so.4.5.0'
        libz-a147dcb0.so.1.2.3 => not found
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp35-cp35m-pygit2/pygit2-0.27.4/pygit2/.libs/libgit2-e2c814dd.so.0.27.8'
        libcurl-e8503455.so.4.5.0 => not found
        libz-a147dcb0.so.1.2.3 => not found
        libssh2-1766d285.so.1.0.1 => not found
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp35-cp35m-pygit2/pygit2-0.27.4/pygit2/.libs/libssh2-1766d285.so.1.0.1'
        libz-a147dcb0.so.1.2.3 => not found
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp35-cp35m-pygit2/pygit2-0.27.4/pygit2/.libs/libz-a147dcb0.so.1.2.3'
Analysing /io/dist/pygit2-0.27.4-cp36-cp36m-manylinux1_x86_64.whl...

pygit2-0.27.4-cp36-cp36m-manylinux1_x86_64.whl is consistent with the
following platform tag: "linux_x86_64".

The wheel references external versioned symbols in these system-
provided shared libraries: libc.so.6 with versions {'GLIBC_2.2.5',
'GLIBC_2.3.4', 'GLIBC_2.3.2', 'GLIBC_2.3', 'GLIBC_2.4'}, librt.so.1
with versions {'GLIBC_2.2.5'}, libdl.so.2 with versions
{'GLIBC_2.2.5'}, libpthread.so.0 with versions {'GLIBC_2.3.2',
'GLIBC_2.2.5'}

The following external shared libraries are required by the wheel:
{
    "libc.so.6": "/lib64/libc-2.5.so",
    "libcurl.so.4": "/usr/local/lib/libcurl.so.4.5.0",
    "libdl.so.2": "/lib64/libdl-2.5.so",
    "libpthread.so.0": "/lib64/libpthread-2.5.so",
    "librt.so.1": "/lib64/librt-2.5.so",
    "libssh2.so.1": "/usr/local/lib64/libssh2.so.1.0.1",
    "libz.so.1": "/lib64/libz.so.1.2.3"
}

In order to achieve the tag platform tag "manylinux2010_x86_64" the
following shared library dependencies will need to be eliminated:

libcurl.so.4, libssh2.so.1, libz.so.1

In order to achieve the tag platform tag "manylinux1_x86_64" the
following shared library dependencies will need to be eliminated:

libcurl.so.4, libssh2.so.1, libz.so.1
Unpacking to: /tmp/pygit2-manylinux1-build.dHVbt28669/cp36-cp36m-pygit2/pygit2-0.27.4
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp36-cp36m-pygit2/pygit2-0.27.4/pygit2/.libs/libcurl-e8503455.so.4.5.0'
        libz-a147dcb0.so.1.2.3 => not found
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp36-cp36m-pygit2/pygit2-0.27.4/pygit2/.libs/libgit2-e2c814dd.so.0.27.8'
        libcurl-e8503455.so.4.5.0 => not found
        libz-a147dcb0.so.1.2.3 => not found
        libssh2-1766d285.so.1.0.1 => not found
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp36-cp36m-pygit2/pygit2-0.27.4/pygit2/.libs/libssh2-1766d285.so.1.0.1'
        libz-a147dcb0.so.1.2.3 => not found
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp36-cp36m-pygit2/pygit2-0.27.4/pygit2/.libs/libz-a147dcb0.so.1.2.3'
Analysing /io/dist/pygit2-0.27.4-cp37-cp37m-manylinux1_x86_64.whl...

pygit2-0.27.4-cp37-cp37m-manylinux1_x86_64.whl is consistent with the
following platform tag: "linux_x86_64".

The wheel references external versioned symbols in these system-
provided shared libraries: libc.so.6 with versions {'GLIBC_2.2.5',
'GLIBC_2.3', 'GLIBC_2.4', 'GLIBC_2.3.2', 'GLIBC_2.3.4'}, librt.so.1
with versions {'GLIBC_2.2.5'}, libdl.so.2 with versions
{'GLIBC_2.2.5'}, libpthread.so.0 with versions {'GLIBC_2.3.2',
'GLIBC_2.2.5'}

The following external shared libraries are required by the wheel:
{
    "libc.so.6": "/lib64/libc-2.5.so",
    "libcurl.so.4": "/usr/local/lib/libcurl.so.4.5.0",
    "libdl.so.2": "/lib64/libdl-2.5.so",
    "libpthread.so.0": "/lib64/libpthread-2.5.so",
    "librt.so.1": "/lib64/librt-2.5.so",
    "libssh2.so.1": "/usr/local/lib64/libssh2.so.1.0.1",
    "libz.so.1": "/lib64/libz.so.1.2.3"
}

In order to achieve the tag platform tag "manylinux2010_x86_64" the
following shared library dependencies will need to be eliminated:

libcurl.so.4, libssh2.so.1, libz.so.1

In order to achieve the tag platform tag "manylinux1_x86_64" the
following shared library dependencies will need to be eliminated:

libcurl.so.4, libssh2.so.1, libz.so.1
Unpacking to: /tmp/pygit2-manylinux1-build.dHVbt28669/cp37-cp37m-pygit2/pygit2-0.27.4
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp37-cp37m-pygit2/pygit2-0.27.4/pygit2/.libs/libcurl-e8503455.so.4.5.0'
        libz-a147dcb0.so.1.2.3 => not found
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp37-cp37m-pygit2/pygit2-0.27.4/pygit2/.libs/libgit2-e2c814dd.so.0.27.8'
        libcurl-e8503455.so.4.5.0 => not found
        libz-a147dcb0.so.1.2.3 => not found
        libssh2-1766d285.so.1.0.1 => not found
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp37-cp37m-pygit2/pygit2-0.27.4/pygit2/.libs/libssh2-1766d285.so.1.0.1'
        libz-a147dcb0.so.1.2.3 => not found
ldd: warning: you do not have execution permission for `/tmp/pygit2-manylinux1-build.dHVbt28669/cp37-cp37m-pygit2/pygit2-0.27.4/pygit2/.libs/libz-a147dcb0.so.1.2.3'

Backref: libgit2/pygit2#793 (comment)

Reproducer
$ git clone git://github.com/libgit2/pygit2.git
$ cd pygit2
$ travis/build-all-manylinux1-wheels.sh pygit2 0.27
# or
$ docker run --network host --rm -v `pwd`:/io -it pyca/cryptography-manylinux1:x86_64 /io/travis/build-manylinux1-wheels.sh pygit2 0.27

@ehashman
Copy link
Member

@webknjaz the issue you're reporting above looks unrelated to this bug, there appears to be something wonky happening with your wheel build such that the RPATHs are still pointed at system locations and ldd can't process it properly. I can try reproducing but I'm not sure this is this issue reported above (which was reported nearly three years ago and I think was fixed in the aforementioned release of auditwheel).

@webknjaz
Copy link
Member

@ehashman probably you're right. Anyway, I've fixed things by compiling deps statically.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants