[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140417081547.GK18458@example.net>
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.
