On Thu, Jun 19, 2014 at 4:24 PM, Bernhard Voelker <[email protected]> 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.
