-
Notifications
You must be signed in to change notification settings - Fork 142
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
Find a replacement for patchelf
#174
Comments
Should we consider forking patchelf to fix issues that affect auditwheel? Or would the maintainers be open to us helping out? Depending on the magnitude of the problems, there's a chance that's easier than modifying auditwheel to use a different tool. |
During the period when we were waiting for NixOS/patchelf#85, we did ship a custom patched build as part of manylinux image. Another possibility to consider: contacting the patchelf maintainers and asking explicitly if they'd be up for adding some python folks as additional patchelf maintainers. |
I agree, we should definitely consider forking I'm planning to open an issue in |
Created NixOS/patchelf#174. Feel free to comment on it if you want to offer help as well. |
I have this patch which uses LIEF instead of The one caveat is that LIEF needs a modern C++ compiler so I had to build it for Taking ownership in Given that this is still a serious change and it can cause unforeseen problems, I was thinking about adding it as an extra, experimental backend to |
It seems that #187 hasn't been merged yet. How can we try out the new patcher? |
LIEF 0.10.0 with proper manylinux1 support is available now so I spent some time updating the PR with the new version. However, I found a problem with RPATH patching which causes some tests to fail as the modified libraries end up containing a null NEEDED entry which triggers an assertion in |
Unfortunately LIEF also has some stability issues. We cannot land #187 until lief-project/LIEF#374 is fixed, which has been open since December. In the meantime I applied my patch to I will close #187 but I plan to extract the new ELF patcher interface from it and land it separately to make the code a bit more modular. It will also make it eaiser to integrate a different patcher if we eventually find an alternative. |
I think the main problem is getting regression tests for patchelf, then releases could be more frequent. |
It would be nice to get the patcher interface from #187 even if not with lief integration. I was thinking of creating a Any thoughts ? |
2 cents from my side. I just experimented in our project where we are using patchelf on several MB sized libraries - NVIDIA/DALI#1950 and LIEF is terribly slow Even printing rpath on a big library takes tens of seconds, replacing needed libraries takes several minutes as well (in case of patchelf it is just several seconds). |
I opened #240 for this.
I think this is a great idea. This would make it much easier to use the master branch of |
Given that we can consider this a fork of If you open issues in the repo for things which need to be done, I can assign myself and start working on them. |
But - is there any reason to keep the binary name? Surely it would reduce the possibility for confusion if we change it to something like |
If we installed the binary under the |
I created issue https://github.com/mayeut/auditwheel-patchelf/issues/1 to discuss things. Also mentioning @rmcgibbo, @jimporter as authors of packages that could do the same with update. The context is bit clearer in this issue so pinging from here for them to have some context. We can discuss furthermore in the linked issue. |
Hey folks. First of all an apology from Nix community that we're neglecting patchelf. I've opened NixOS/patchelf#199 to help out here a bit. |
0.11 was just released today with fixes for all the listed patches here. |
That is great news! Much appreciated @domenkozar. |
With 1.3 released and a new maintainer, are you still seeing bugs? |
I don't recall any recent issues and I think all of the ones I mentioned in the description have been fixed. Now that |
Sorry to be late to the party on this one, but I am on Ubuntu 20.04 and I don't seem to be able to install a newer version of This is probably an Ubuntu problem, and not yours. But has anyone hit this problem before? UPDATE for future readers: I have a server that I would have preferred to keep on Ubuntu 20.04 for 1 more year (until the release of 24.04, the LTS). But I had to abandon that notion. Updating Ubuntu to 22.04 solved the impossible quagmire of |
We rely on the
patchelf
project to repair ELF files but unfortunately it has several bugs and the fixes often take a very long time to land in a release. Releases also seem to be very infrequent.A few example issues we have faced:
patchelf
.I think it would be useful to look at potential alternatives so that we can resolve similar issues quicker. The tasks
patchelf
implements inaudithweel
today are:DT_NEEDED
sectionSONAME
RPATH
If we can find a replacement which can do these, has fewer bugs and ideally a healthier release cycle, we could consider replacing
patchelf
.One potential viable alternative I found is LIEF. I think it does everything we need, but I have to test it out. It's also a wrapper around a C++ project and it does not seem to ship wheels which is problematic, but we might be able to help with that.
I'm curious if anyone knows of other alternatives we could consider.
The text was updated successfully, but these errors were encountered: