When trying to emerge libstdc++-v3-3.3.3-r1 with bash-3.0, I get: creating auto-host.h trap: usage: trap [-lp] [[arg] signal_spec ...] !!! ERROR: sys-libs/libstdc++-v3-3.3.3-r1 failed. !!! Function src_compile, Line 177, Exitcode 1 !!! (no error message) Reproducible: Always Steps to Reproduce: 1. Install bash-3.0 2. `emerge libstdc++-v3` Actual Results: see above Expected Results: used the new syntax for 'trap', and thus not crashed. I don't know if this is a problem with libstdc++-v3 or autoconf, or something else.
Created attachment 36356 [details] fix for faulty trap usage It seems that "trap 0" has to be replaced with "trap '' 0" at two points in the configure script. Patching a generated file feels a bit ugly, but to me it doesn't seem like those lines come from any input file, so could it be an issue with autoconf?
This kills our sparc64 compiler too. Removing ~sparc keyword from bash for now.
Created attachment 36357 [details] updated fix A few things struck me: 1) The correct syntax should be "trap - 0" (updated patch) 2) This has to be a bug in sh, since the usage message tells us that "trap signal_spec" should be allowed 3) Since this is the main gcc configure script, it should break all gcc ebuilds (which someone here seems to have discovered the hard way). Perhaps bash-3.0 should be masked from all archs for now?
gcc-3.3.3-r6 dies on the trap syntax, but gcc-3.4.1 doesn't. Still, that's rather serious.
It's not a bug in bash, but rather the bash developers are trying to adhere more closely to POSIX: bash -c 'trap 0' # fine sh -c 'trap 0' # errors In this case I don't think the POSIX compliance is worthwhile until autoconf catches up, so I've patched it to behave the way we want for bash-3.0-r1. Thanks for the bug report.
Well, accuse me of being picky, but in that case I think that they should change the usage message to one that actually forbids that syntax =P.
