-
Notifications
You must be signed in to change notification settings - Fork 85
'strip' binary included in linuxdeploy bundle fails when binaries contain section `.relr.dyn' [0x13] #311
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
Comments
Is there a specific reason you're building on such a recent system with linuxdeploy? Your binary won't be compatible with any other distro. That said, you can just strip everything ahead of time, then use |
I'm building it on this recent system because it's what I have in front of me and I'm flushing out the release flow. :) But more importantly, this will be a problem for "stable" build systems in the very near future. Thanks for the NO_STRIP tip, I'll use that as a workaround to make sure there are no other issues before I go through the process of figuring out how old of a builder I can get away with.. |
I'm open to introducing an environment variable to make it configurable or building a more recent, known stable version of strip. Please test your application on other distros, too, to see whether the |
Confirming the same issue: Click to See the ERROR LOG
Helps though . . . Did not you think about adding support for building directly from the |
I am attempting to run this on Fedora 41; the binaries are built with gcc 14.2, binutils 2.43.1, and glibc 2.40, which is fairly recent but I note that support for section 0x13 was added in binutils 2.38, released more than three years ago (Feburary 2022).
...So if linuxdeploy used the system 'strip' binary instead of the bundled one, this error would have not occurred.
Is it possible to update the bundled strip binary (and other binutils bits) to 2.38 or newer?
The text was updated successfully, but these errors were encountered: