libz.so.1.2.3 on CentOS 6 causes repair to segfault #161
Description
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?