Date: Thu, 17 Apr 2014 10:15:48 +0200 From: u-igbb@...ey.se To: musl@...ts.openwall.com Subject: --library-path and friends (was: musl 1.1.0 released) On Wed, Apr 16, 2014 at 12:53:52PM -0400, Rich Felker wrote: > I'm committing a patch based loosely on yours that accepts more forms > (e.g. --preload=...) and one additional option (--list). Let me know > if it fails to meet your needs and I can improve it. Without having looked at the code yet: 1. This is quite certainly just fine. My needs are very basic, as long as it accepts "--library-path <somepath>" which fully overrides LD_LIBRARY_PATH (not resetting it of course) and --preload with a corresponding semantics, then I am in business and happy. --list is welcome! 2. Not every feature is certainly for good :) Frankly I do not see any need for the '=' syntax extention, it probably costs some extra byte[s] but more importantly once introduced you will have to keep the extra possibility. I do not think (didn't check for a while though) that either glibc or uclibc accept the '=' form. A difference between the acceptable syntax variations in different libraries would quite certainly confuse some people. These options imho are expected to be used mostly in scripts (I never type "--library-path" on a command line :) so keeping the syntax as uniform as possible will help reusability and make the usage of the feature less error prone. But this "as narrowly defined interface as sufficient" is just a suggestion. Of course a richer inteface (the '=') will not influence my usage in any way. 3. Why I care about "reusability" between libraries: A "homogenous" c-library base (as of versions and/or implementations) for all applications is unthinkable here. We have no limitations on which versions of which applications compiled with which options and linked against which versions of which libraries (compiled with which options and so on) can be run. Any of them or many simultaneously on the same computer are run as needed, easily. Musl fits there very well, among others due to its stable ABI, but the whole picture can probably never become "musl-only" just because we avoid placing arbitrary constraints. (If an application for some reason does need uclibc or glibc or something else, it will be given the opportunity.) To make all of this work depends among others on the libraries themselves not placing arbitrary constraints - nicely, musl does a great job! Thanks Rich. Rune
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.