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

[Alex Deymo]

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.

> b) As space is the argument for using --enable-single-binary,
> shouldn't a stripped install be the default there?

I think that should be up to the user. Less implicit settings are
better :) (you might want to split the debug information as we do in
gentoo rather than just strip it)

> c) Finally, it'd be good to have a test case for the new
> 'coreutils' binary. ;-)

Most aspects are being tested: --help, --version, invalid options, and
the symlinks in src/ point to that binary, so every test implicitly
tests that the multicall mechanism works. What scenarios would you
like to test specifically for this binary?

I'll send a new patch tomorrow and look at those failures; but I'd
like to know what do you think about these ideas.

Thanks,
deymo.