Re: [PATCH v2] build: Option for building all tools in a single binary

[Mike Frysinger]

On Fri 20 Jun 2014 12:29:41 Pádraig Brady wrote:
> On 06/20/2014 10:36 AM, Alex Deymo wrote:
> > On Thu, Jun 19, 2014 at 4:24 PM, Bernhard Voelker wrote:
> >>>  # '/bin/sh -i', rather than '/bin/sh -- -i', which doesn't do what we
> >>>  want.
> >>>  # Avoid the issue by using an executable rather than a script.
> >>>  # Test -u, rather than -i, to minimize PATH problems.
> >>> 
> >>> -ln -s "$abs_top_builddir/src/echo" ./-u || framework_failure_
> >>> +echo "#!$abs_top_builddir/src/echo" > ./-u || framework_failure_
> >>> +chmod +x ./-u || framework_failure_
> >> 
> >> This looks problematic - as the change contradicts the explicit comment
> >> about avoiding a script.  Why should a symlink to src/echo (which in turn
> >> is a symlink to coreutils) not work?
> > 
> > This problem is related with the single binary (or multicall binary)
> > approach. If you create the file ./-u as a symlink to src/echo which
> > in turns it is a symlink to coreutils, the coreutils program will see
> > "./-u" as the argv[0], which was being used to determine the program
> > to call. if the ./-u symlink points to src/echo or something else is
> > not distinguishable by the coreutils program.
> > 
> > So, we were discussing this with vapier@ and since people likes to
> > symlink to these tools, we though we could use hash-bangs like this:
> > the file /bin/true will contain "#!/bin/coreutils
> > --coreutils-prog=true". When you create a symlink to it like ./-u (or
> > call it directly), the coreutils program sees argv as:
> > "/bin/coreutils" "--coreutils-prog=true" "./-u" ...more-options...
> > That file will likely fit in 60 chars (unless your --prefix= is bigger
> > than 14 chars) which means that in ext2/3 systems the file fits on the
> > inode and doesn't need a data block! \m/
> > 
> > The downside of this is that we kinda need to know the absolute path
> > of /bin/coreutils (since relative paths don't work well with that).
> > For the install part this is not a problem (since --prefix= is already
> > absolute) but for the tests (check/distcheck) that might be a bit more
> > tricky.
> 
> The above scheme handles the issue of multiple levels of symlinks.
> Another thing to consider is how the above scheme might effect
> /proc/$pid/{comm,cmdline} etc. I.E. would the explicit exec of
> /bin/coreutils now have that as comm, thus breaking some scripts, or
> impacting commands like: killall -USR1 dd ?
> 
> Multiple levels of symlinks seems a bit like an edge case TBH
> which could need the "full fat" version of coreutils to support?

unfortunately, symlinking tools to stub them out (like `true` and `false`) is 
kind of common :(
-mike

signature.asc
Description: This is a digitally signed message part.