Summary: | New 'trap' usage in bash-3.0 breaks libstdc++-v3 build. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Greg <grege> |
Component: | [OLD] Library | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | sparc |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
fix for faulty trap usage
updated fix |
Description
Greg
2004-07-28 15:15:44 UTC
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. |