Open atwilso opened 2 years ago
I can't find much info on this. How the library is built might be affected by your version of Xcode, so see if you can update that and rebuild.
If libboost_atomic.dylib
is deliberately built without padding then I don't think Delocate can do anything about it.
I don't think it's my compiler version. The libraries that I built myself get processed by delocate-wheel with no fuss.
I don't have any control at all over how libboost_atomic.dylib
is built. I suspect that it isn't being created deliberately without padding because several other Boost libraries are included in this wheel and get processed with no fuss.
I could theoretically work around this by building Boost from source myself, but that involves a major revamp of my CI pipeline. Also, there's a lifetime limit on how many times a body can build Boost from source before the universe collapses, and I'm pushing it as it is...
Is it possible to find out how much room for install_name changes is available in any particular binary? Is it possible to have delocate generate shorter names?
Bug: delocate-wheel 0.9.1 or newer causes
install_name_tool
to error out on some libraries with the following error:There are a bunch of libraries in the wheel. Most of them get processed without incident. There's just something special about
libboost_atomic
that runs into this size limit.If this were happening in the code I build myself, I could just add the magic linker flag myself. However, Boost is installed via Anaconda and I don't control their build configuration.
I'm building against a Conda environment containing CPython 3.7.10 and Boost 1.75, both installed from
conda-forge
.To reproduce:
delocate-wheel test-wheel.whl
with delocate 0.9.1 or newer.I have a wheel file I can supply for debugging. It's 31MB and Github won't let me attach it to this message. Contact me and I'll arrange to get it to you.
Platform: