sys-apps/fakeroot-1.8.1 and also -1.9 (earlier versions not tested) fail when /bin/sh is a symlink to /bin/dash. According to the messages, the reason is that the configure script tests whether the shell understands += (the test succeeds because it is run by bash) and only afterwards decides which shell to use (which is the shell to which /bin/sh points). The easiest solution would be if upstream would remove the superfluous += treatment completely: It is only used in one function and obviously is incompatible and has no advantage. As a temporary hack, one could just let the test fail: sed -e 's/\(shell_append.*\)yes/\1no/' configure
try exporting CONFIG_SHELL=/bin/sh before emerging fakeroot
(In reply to comment #1) > try exporting CONFIG_SHELL=/bin/sh Works like a charm. That's a much cleaner solution than my hack, of course. Now I am not sure whether to close this bug: Is this recommended for all autotools stuff (i.e. should I actually put this in my /etc/make.conf) or is this a particular "feature" of fakeroot's autotools usage? In the latter case, I suppose the export command should happen in the ebuild.
it's a nested mess ... configure will re-exec itself with a "better" shell so that even if /bin/sh is broken, it'll get a less broken shell while executing unfortunately, that means embedded shell tests (while logically they should be ok), actually arent representative of the the real /bin/sh shell ... it'll have to create a new shell script like: cat <<EOF > moo #!/bin/sh <test for the += crap> EOF and then execute moo looking at the m4 macros makes it look like this test comes from libtool, but i cant find any corresponding code in libtool itself at any rate, i'll push this to the debian peeps and use CONFIG_SHELL in our ebuild
