On 06/04/16 09:39 +0200, Eric Botcazou wrote:
Hi,we recently ran into build failures on Windows systems using a somewhat old grep, coming from a syntax error in the libstdc++-symbols.ver version file: # Symbol versioning for shared libraries. if ENABLE_SYMVERS libstdc++-symbols.ver: ${glibcxx_srcdir}/$(SYMVER_FILE) \ $(port_specific_symbol_files) cp ${glibcxx_srcdir}/$(SYMVER_FILE) $@.tmp chmod +w $@.tmp if test "x$(port_specific_symbol_files)" != x; then \ if grep '^# Appended to version file.' \ $(port_specific_symbol_files) /dev/null > /dev/null 2>&1; then \ cat $(port_specific_symbol_files) >> $@.tmp; \ else \ sed -n '1,/DO NOT DELETE/p' $@.tmp > tmp.top; \ sed -n '/DO NOT DELETE/,$$p' $@.tmp > tmp.bottom; \ cat tmp.top $(port_specific_symbol_files) tmp.bottom > $@.tmp; \ rm tmp.top tmp.bottom; \ fi; \ fi Note the double /dev/null on the grep command line. The first one causes the grep to fail when the command is invoked on these systems. That's old code, but it is now invoked for config/abi/pre/float128.ver on the mainline and 5 branch and this breaks the build on these systems (4.9 builds fine). This first /dev/null doesn't serve any useful purpose and seems to be a typo,
Doesn't it mean that if $port_specific_symbol_files contains only whitespace we don't hang waiting for input from stdin? The 'if' above it will be true when "x$port_specific_symbol_files" = "x " or similar. I don't see any way for that to happen in the FSF tree, so it should be safe. I'm a bit concerned about making that change this late in stage 4 though. There isn't much time to find out if it breaks an obscure target.
