bin/45269: sh fails to strip trailing newline in command substitution, breaking build

[gson%gson.org@localhost (Andreas Gustafsson)]

>Number:         45269
>Category:       bin
>Synopsis:       sh fails to strip trailing newline in command substitution, 
>breaking build
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Aug 19 09:05:00 +0000 2011
>Originator:     Andreas Gustafsson
>Release:        NetBSD 5.1_STABLE of 2011-04-25
>Organization:
>Environment:
System: NetBSD babylon5.NetBSD.org 5.1_STABLE NetBSD 5.1_STABLE (GENERIC) #4: 
Mon Apr 25 09:34:00 UTC 2011 
root%franklin.NetBSD.org@localhost:/home/netbsd/5/amd64/kern-compile/GENERIC 
amd64
Architecture: x86_64
Machine: amd64
>Description:

Since GCC 4.5 was enabled on x86 by mrg's commit of bsd.own.mk 1.678
(CVS date 2011.08.07.08.15.02), every i386 release build on the TNF
automated test server babylon5.netbsd.org has failed, as can be seen at

    
http://releng.netbsd.org/b5reports/i386/commits-2011.08.html#2011.08.07.08.15.02

The failures occur during the linking of libmpfr:

    libtool: link: ranlib
     .libs/libmpfr.a
    Usage: ranlib [options] archive

The ranlib comman fails because obj/tools/mpfr/build/config.status contains

    # Commands used to install an old-style archive.
    RANLIB="ranlib
    "

with a newline character between the ranlib command and the trailing
double quote.  In config.status, there is similarly

    RANLIB='ranlib
    '

but in config.log, there is no extra newline:

    RANLIB='ranlib'

The libtool script is generated by configure; it appears that the
shell running the configure script is failing to strip the trailing
newline from the output of a command substitution when generating the
RANLIB line.

A similar problem in a package build was reported in pkg/45052.

I have marked this bug as critical because:

 1) NetBSD can no longer be reliably built on a NetBSD host

 2) it has rendered the TNF automated test infrastructure inoperable

>How-To-Repeat:

The bug can be a bit tricky to reproduce; pkg/45052 reports that
adding some printf or echo commands can make it go away, and my own
tests indicate that doing the build in a directory whose pathname has
a significantly different length from that used by the automated build
scripts also makes it go away.  But the automated build scripts do
reproduce it reliably, and the following also works for me:

1. If you are not a developer, become one :)

2. Ask admins for an account on babylon5.netbsd.org and log in.

4. Create a directory whose name is 38 characers long; let's call this
directory "$d".  For example, I used:

   d=/mnt2/gson/aaaaaaaaaaaaaaaaaaaaaaaaaaa
   mkdir $d

4. Then run:

   cd $d
   CVSROOT="anoncvs%anoncvs.NetBSD.org@localhost:/cvsroot" cvs checkout -D 
2011.08.13.12.18.54 src
   cd $d/src
   ./build.sh -D $d/destdir -R $d/release -T $d/tools -O $d/obj -m i386 -a i386 
-U release

5. Watch the build fail.

>Fix: