[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 17 May 2017 12:24:28 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Question about setting argv[0] when manually using
dynamic linker
On Wed, May 17, 2017 at 11:16:51AM -0500, John Regan wrote:
> On Wed, May 17, 2017 at 11:07 AM, mzpqnxow <musl@...qnxow.com> wrote:
>
> > BTW, the shell built-in "exec" has -a which can be used to set argv[0]
> >
> > Again though, I'm not entire sure I understand your use, so ignore this if
> > it's irrelevant :>
> >
> > On Wed, May 17, 2017 at 07:00 mzpqnxow <musl@...qnxow.com> wrote:
> >
> >> Is there any reason you want to avoid simply statically linking the
> >> program(s) so that it needs no libc or other shared objects at all?
> >>
> >> Or did I misunderstand what you're trying to do?
> >>
> >> On Wed, May 17, 2017 at 05:05 <u-uy74@...ey.se> wrote:
> >>
> >>> On Tue, May 16, 2017 at 08:38:56PM -0400, John Regan wrote:
> >>> > Hi there - I was wondering if it's possible to somehow set argv[0] when
> >>> > calling the dynamic linker to load a program.
> >>> ...
> >>> > I'd like to retain whatever was actually typed on the command line (in
> >>> this
> >>> > case, set argv[0] to "app"), since many apps look at argv[0] to change
> >>> > behavior, ie - gzip vs gunzip.
> >>> >
> >>> > I tried seeing if there was some switch I could pass to the linker,
> >>> etc -
> >>> > as far as I can tell, there's no easy way to do this.
> >>>
> >>> Set argv[0] to whatever you need when you exec*() the dynamic loader,
> >>> which is straightforward with a binary wrapper (not with a shell).
> >>>
> >>> A binary wrapper also adds less overhead then going through a shell.
> >>>
> >>> There is imho hardly any incentive to put such functionalty into the
> >>> loader. I say this even though we are dependent here on such tricks,
> >>> to work around programs which insist on guessing things when not asked
> >>> to.
> >>>
> >>> Regards,
> >>> Rune
> >>>
> >>>
> Well, if I statically link I'm unable to dynamically load modules (at least
> I'm pretty sure that's the case). There's some cases where that might be
> useful.
>
> Right now, I'm really just trying to see "is this doable?". It'd be
> interesting to be able to distribute a program with its own libc,
> libraries, etc, and still have the ability to dynamically load modules.
You're right about static linking and dlopen, and what you're doing is
a completely reasonable and recommended way for deploying dynamic
linked apps in a self-contained way that doesn't depend on musl libc
on the host. Unfortunately there's no way to set argv[0] like you want
at this time. Perhaps adding an option like --argv0=foo would be
appropriate.
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.
