Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 18 Apr 2014 16:46:22 -0400
From: Rich Felker <>
Subject: Re: --library-path and friends (was: musl 1.1.0

On Thu, Apr 17, 2014 at 10:15:48AM +0200, 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.


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.