[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140418204621.GM26358@brightrain.aerifal.cx>
Date: Fri, 18 Apr 2014 16:46:22 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: --library-path and friends (was: musl 1.1.0
released)
On Thu, Apr 17, 2014 at 10:15:48AM +0200, u-igbb@...ey.se wrote:
> 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!
Yes. And it makes it possible to implement ldd as a shell script using
ld-musl with --list rather than as a symlink to ld-musl. This is
probably better in that it works even if the desired argv[0] does not
get passed to ldd.
> 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
I'm not sure whether glibc's dynamic linker supports it, but the
processing of the form with --option=arg is part of the "standard"
getopt_long processing for long options, and I felt like it should be
supported here too for the sake of consistency if we're accepting long
options that look like getopt_long options. It's just one extra
(trivial) line of source anyway.
Rich
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.
