libz.so.1.2.3 on CentOS 6 causes repair to segfault

[romaingz]

Hi,

OS: CentOS 6.10
libz.so: 1.2.3
python: 3.6.6
patchelf: 9.0

I've just run into an issue with libz.so with its 1.2.3 version on CentOS 6.
When repairing I get the following error:

DEBUG:auditwheel.repair:Grafting: /lib64/libz.so.1.2.3 -> .libs_MyLib/libz-70dc5473.so.1.2.3
Traceback (most recent call last):
  File "/home/path/to/venv/bin/auditwheel", line 11, in <module>
    sys.exit(main())
  File "/home/path/to/venv/lib/python3.6/site-packages/auditwheel/main.py", line 47, in main
    rval = args.func(args, p)
  File "/home/path/to/venv/lib/python3.6/site-packages/auditwheel/main_repair.py", line 79, in execute
    update_tags=args.UPDATE_TAGS)
  File "/home/path/to/venv/lib/python3.6/site-packages/auditwheel/repair.py", line 88, in repair_wheel
    new_soname, new_path = copylib(src_path, dest_dir)
  File "/home/path/to/venv/lib/python3.6/site-packages/auditwheel/repair.py", line 141, in copylib
    check_call(['patchelf', '--set-soname', new_soname, dest_path])
  File "/home/other/path/to/Python/3.6.6/lib/python3.6/subprocess.py", line 291, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['patchelf', '--set-soname', 'libz-70dc5473.so.1.2.3', '.libs_MyLib/libz-70dc5473.so.1.2.3']' died with <Signals.SIGSEGV: 11>

I also get a segfault if I simply try to --print-soname.
Note that there is no similar issue with the libz.1.2.7 on CentOS 7.

It turns out that I really don't need libz to be included in this process, since (at least on all our CentOS systems) it comes already installed.

I temporarily worked around that by wrapping the copylib into a try/except block:

try:
    new_soname, new_path = copylib(src_path, dest_dir)
    soname_map[soname] = (new_soname, new_path)
    check_call(['patchelf', '--replace-needed', soname, new_soname, fn])
except Exception as e:
    logger.warning(str(e))

and it works.
My repaired wheel can be installed and the dependency to libz.so gets resolved on the target system to the one in /lib64/.

I also thought about playing with the whitelist in policy.json.

I'm not sure if this is related to #152.

Is there a way that I missed to solve my issue without changing the audhitwheel code?
Would it be beneficial to allow a user to specify a list of libs for auditwheel to ignore?

[dsteinmo]

I also hit this (or something similar) with --platform manylinux2010 and a C++ project, container img dockcross/manylinux2010-x64 and libcrypt-2.12.so . May be a separate issue related to the fact that there is versioning information in the filename instead 'libcrypt-2.12.so' which auditwheel transforms to libcrypt-2-<XXXXXXXX>.12.so