Improve messaging about 'strip'
alugowski opened this issue · comments
Like many folks, I recently got one of these messages:
RuntimeError: Unable to rename the dependencies of libgraphblas.dll because this DLL has trailing data. If this DLL was created with MinGW, run the strip utility. Otherwise, include libgomp-1.dll;libgcc_s_seh-1.dll in the --no-mangle flag. In addition, if you believe that delvewheel should avoid name-mangling a specific DLL by default, open an issue at https://github.com/adang1345/delvewheel/issues and include this error message.
Could we improve the messaging on what "run the strip utility" means? Some of us only deal with Windows inside a GitHub Actions runner and experimentation gets tedious.
- Is
stripa Windows command or do I need to install it? Is it just the GNU binutils utility? - What
striparguments does delvewheel need? I triedstrip libgraphblas.dll(with full path) and saw the same message again.
The list of thingsstripcan strip is long:
strip [-F bfdname |--target=bfdname]
[-I bfdname |--input-target=bfdname]
[-O bfdname |--output-target=bfdname]
[-s|--strip-all]
[-S|-g|-d|--strip-debug]
[--strip-dwo]
[-K symbolname|--keep-symbol=symbolname]
[-M|--merge-notes][--no-merge-notes]
[-N symbolname |--strip-symbol=symbolname]
[-w|--wildcard]
[-x|--discard-all] [-X |--discard-locals]
[-R sectionname |--remove-section=sectionname]
[--keep-section=sectionpattern]
[--remove-relocations=sectionpattern]
[-o file] [-p|--preserve-dates]
[-D|--enable-deterministic-archives]
[-U|--disable-deterministic-archives]
[--keep-section-symbols]
[--keep-file-symbols]
[--only-keep-debug]
[-v |--verbose] [-V|--version]
[--help] [--info]
objfile...Suggestion: follow homebrew's example for similar circumstances: emit the command you need me to run (with switches and dll name included). Even better, test for the presence of strip and just run it for me. Possibly if enabled with a --autostrip switch if you wish.
strip -s ...path/*.dll
or
strip -s ...path/libgraphblas.dll
@bigcat88 has provided the correct strip command. I have submitted an improvement to the error message and will look into the possibility of running strip automatically.
strip -s ...path/*.dllorstrip -s ...path/libgraphblas.dll
Appreciate it, but the GitHub Actions version of strip appears to require more than that. A simple strip -s resulted in the same delvewheel message, so I tried strip -s -v and got this:
copy from `C:/Program Files (x86)/bin/libgraphblas.dll' [pei-x86-64] to `C:/Program Files (x86)/bin/stiG2Kb7' [pei-x86-64]
Does that mean I'm supposed to somehow tell delvewheel to use stiG2Kb7 instead?
@adang1345 Appreciate the change! --strip still doesn't work for me in GitHub Actions, though, probably due to the output above. The new messages, though, are exactly what I was looking for, thank you!
(I've been using the --no-mangle workaround, but I'd rather get the strip version working)
Can you give me a link to a GitHub Actions run where you are experiencing the issue?
@alugowski I took a look at https://github.com/alugowski/python-suitesparse-graphblas and discovered why strip is not working for you. Your build of libgraphblas.dll contains the .eh_frame section, which is responsible for 14 bytes of trailing data at the end of libgraphblas.dll. This section prevents name-mangling and cannot be removed with strip.
Based on https://stackoverflow.com/questions/26300819/why-gcc-compiled-c-program-needs-eh-frame-section, it looks like you can prevent the .eh_frame section from being created using the -fno-asynchronous-unwind-tables compiler flag.