On 07/04/2014 05:06 PM, Pádraig Brady wrote: > On 07/02/2014 04:34 PM, Pádraig Brady wrote: >> On 07/02/2014 01:44 AM, Alex Deymo wrote: >>> Hi again, >>> >>> Sorry for the delay with this patch. Here is patch v7 attached. >>> >>> *** symlinks vs shebangs: >>> >>> * Other projects use symlinks to have a multicall binary; including busybox >>> and toolbox which cover similar functionality as coreutils; but not limited >>> to them: lvm (vgcreate, pvcreate, etc), xz (xzcat, unxz point to "xz") and >>> others I'm not aware of. >>> >>> * People using symlinks do not protect against the symlink to symlink case; >>> they just rely on argv[0]. symlink to symlink is not the only way to >>> provide a different argv[0]; you can pass whatever you want as the first >>> argument of argv when you call exec(). >>> >>> * The scheme to follow symlinks to determine which one was the last symlink >>> requires to accurately reproduce the path search algorithm used by exec() >>> on the platform we are running; and requires the make a couple of syscalls >>> just to know what's the tool to call, yet still doesn't solve the whole >>> case. >>> >>> * Shebangs allow you to have a symlink to them and it still works without >>> extra work. On some systems, we can change the value of /proc/$PID/cmdline >>> and other files to not break use cases like "killall foo" or the result of >>> "ps". >>> >>> >>> In general, if you want to use --enable-single-binary is because size is a >>> concern; and in those cases you know your environment (you are deploying an >>> embedded system with a particular kernel). You might not care about 4MB in >>> a multi GB linux distro and there's people out there still doing symlink to >>> symlink that eventually will get their scripts right; but not yet. >>> >>> So, I added an option where you can choose at configure time if you want to >>> install symlinks or shebangs (--enable-single-binary=shebangs for example). >>> I tested this patch on the ChromiumOS builders and it worked (we managed to >>> build a builder environment and images for amd64, x86 and arm). >>> >>> In the shebang case, the program will attempt to modify /proc/$PID/cmdline >>> by using prctl() if available. There are other ways to modify argv[] on >>> other platforms (look at the sendmail or postgresql case for example), so >>> eventually we should migrate that functionality to a gnulib file and make >>> it work on all the supported platforms... but for now, you still have the >>> choice to use symlinks if that works for you. >>> >>> Let me know if you have other questions about this patch and happy canada >>> day for the canadians out there on this list. >>> >>> deymo. >>> >> >> Excellent work. >> >> One small issue I noticed (in symlinks mode at least) >> was that `make syntax-check` causes all the >> tools to be remade as stand-alone binaries. >> This is related to `make src/$binary` replacing >> the symlink with a stand-alone binary. >> >> Note that isn't a supported end user mode anyway, >> so it's not blocking, though nice to avoid. >> >> As an aside, the reason end users can not do: >> make src/$binary >> is due to our use of BUILT_SOURCES of which the automake manual says: >> "you cannot use BUILT_SOURCES if the ability to run >> ‘make foo’ on a clean tree is important to you." >> coreutils uses BUILT_SOURCES, as the mandatory configure >> step is expensive compared to the build itself, >> so there is not much advantage to supporting that. >> >> A more problematic issue is that program prefix isn't supported. >> i.e.: ./configure --enable-single-binary --program-prefix=g >> >> BTW I've attached some spelling fixes which I've rolled in here. >> >> thanks! >> Pádraig. >> > > Getting ready to merge this. > Attached are the following adjustments:
Rolled up for easy application on master: http://www.pixelbeat.org/cu/single-binary_v8.patch Pádraig.
