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

[Pádraig Brady]

On 06/20/2014 10:36 AM, Alex Deymo wrote:
> On Thu, Jun 19, 2014 at 4:24 PM, Bernhard Voelker
> <address@hidden> 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?

Maybe one could do something like the following pseudo code.

  if (name not found)
    {
      exec_path = find_exec_path(argv[0]);
      char * name = exec_path;
      char * target;

      /* find penultimate link name.  */
      while (true)
        {
          char * target = xreadlink (name);
          if (! STREQ (target, name)
            name = target;
          else
            break;
        }

      prog = basename (last_target);
    }

Actually the above is kind of a more general form of set_program_path() in 
stdbuf.c.
See also the comments on that function. Perhaps we could generalize that 
function?

As a general point I wouldn't jump through too many hoops
to handle the multiple levels case, either in the tests or in coreutils.c.

thanks,
Pádraig.