[Rpm-maint] [rpm-software-management/rpm] elfdeps: Generate dependencies on non-executable shared libraries (#1393)
Neal Gompa (ニール・ゴンパ)
notifications at github.com
Mon Nov 23 15:13:27 UTC 2020
> They're not incompatible with each other, but for the purpose of addressing the issue that libraries should not have to be packaged as executable, #1394 kills the ability to chmod a-x to disable dependency generation for all ELF files, whereas #1395 doesn't.
Maybe my understanding of the history is wrong, but I thought the reason we had the `chmod a-x` hack in the first place was that we didn't have _any_ other way to filter dependencies. Now we have the ability to apply autodep filters based on file names/paths independent of a specific generator, so this hack is no longer needed in the first place.
> But then the latter requires libraries to be executable in the first place, which is a bit silly but that's how at least autotools installs them. Dunno about newer build-tool chains.
While Autotools, CMake, and Meson all do set libraries to be executable by default, many other toolchains do not. Especially a lot of the custom "portable" ones that come from a Windows-centric don't, since marking a DLL as executable does nothing since DLLs differ from executables by missing the marker in the file that indicates it can be executed rather than requiring an "interpreter".
> Maybe the real "issue" behind this all is that perhaps it's time to admit that the executable bit as a marker for dependency generation has long since stopped being meaningful. And if it's not meaningful for one thing then should it be meaningful for anything at all then?
Perhaps. We have a richer ways of doing things these days, but I can't say for certain if nobody relies on the `exeonly` thing for other stuff.
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rpm-maint