when bash is installed, configure will always prefer and use bash, so in order to reproduce one has to temporarily uninstall, remove or rename his bash binary. when /bin/sh is busybox' ash, the following error breaks the build: gdb-7.6.2/opcodes/configure: .: line 12678: can't open '../../opcodes/configure.host' inserting debug code into bfd/configure shows that it's actually bfd/configure that is running, instead of opcodes/configure (as displayed): bfd/configure + echo XXX ${srcdir}/configure.host XXX > /dev/tty # Permit host specific settings. . ${srcdir}/configure.host displays: XXX ../../opcodes/configure.host XXX gdb-7.6.2/opcodes/configure: .: line 12680: can't open '../../opcodes/configure.host' with debian's dash as /bin/sh, one gets the following error: gdb-7.6.2/opcodes/configure: 3235: ./configure.lineno: Syntax error: "fi" unexpected both dash and busybox ash are strictly posix conformant sh implementations, and work fine for all other packages including binutils 2.24. to me it looks like there happened some typo somewhere, and the syntax error is not detected/properly handled by bash (so it works by chance), or some bashism crept into the build at some point, without being noticed as bash is even in debians baseinstall. this error did not happen with gdb 7.4. the commit that introduced the bug can probably quickly be found using a git bisect on a box that has /bin/bash symlinked to /bin/dash the configure line used to build gdb was: LDFLAGS="-static" \ CFLAGS="-D_GNU_SOURCE -D_LARGEFILE64_SOURCE -O0" \ ../configure -C \ --prefix= --disable-werror --disable-tls --with-system-zlib=yes \ --enable-64-bit-bfd --enable-targets=x86_64-linux,i386-linux,powerpc-linux,arm-linux,mips-linux,mipsel-linux,microblaze-linux \ --disable-sim --disable-tui
update: 7.5.1 is the latest version that works with dash symlinked to /bin/bash and /bin/sh. 7.6(.0) is the first version that fails.
Thanks for the bug report. I'm not able to reproduce this. I am using Fedora 19 here, and did what you recommended (installed dash, symlinked bash -> dash, sh -> dash), but configure runs fine for me on both git HEAD and the 7.6 .tar.bz2. BTW, do you see this bug using git HEAD?
the same happens for binutils 2.24. there must've been some bashism that crept into the configure (config.sub/.guess/.host etc) infrastructure during the last year. sorry i didn't have time yet to experiment with latest git :/
It would be very useful if you could identify which kind of "bashism" you're talking about. As I said, I could not reproduce the bug, so there is nothing I can do to fix it. I will wait a few more weeks until you provide more input.
I have bumped into same problem on Alpine Linux and binutils-2.24. I use busybox ash as /bin/sh. (ln -s /bin/busybox /bin/sh) It happens both with uclibc and musl libc and binutils-2.24. I does not happen with binutils-2.23. I created a fedora-20 vm and tried to reproduce it there too but I am not able to either. I was not able to reproduce it with /bin/dash so I suspect this is a bug in recent busybox ash that does not affect the acient busybox shipped with fedora 20.
After more digging in the generated autoconf, it seems that there is something wrong with the generated configure.lineno. If I regenerate configure scripts with autoconf 2.69 it all works again. My guess is that the version of autoconf used to generate the tarballs is buggy.
I finally found a way to reproduce it on fedora-20 and binutils-2.24: yum install busybox mv /bin/sh /bin/sh.backup ln -s /usr/sbin/busybox /bin/sh CONFIG_SHELL=/bin/sh ./configure make configure-host Some things to note: CONFIG_SHELL=/bin/ash ./configure does not trigger it. This is from configure.lineno: ... for as_base in sh bash ksh sh5; do # Try only shells that exist, to save several forks. as_shell=$as_dir/$as_base ... note that it does not check for "ash". configure will find and use /bin/bash if it exists - even if /bin/sh points to something else. So rename /bin/bash might also trigger it (careful though.. its the shell for root so you can easily brick your fedora box...) I was not able to trigger it with dash. I think this is becuase recent versions of dash has support for $LINENO, so it does not use sed to generate configure.lineno (where i think the problem is). (see under LINENO on http://www.gnu.org/software/autoconf/manual/autoconf.html#Special-Shell-Variables) I think it might be possible to trigger it with dash on (older?) debian. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582952 My conclusion is that something is broke with the generation of configure.lineno in the version of autoconf that created the tarball. (2.64).
This change/revert appears to fix it: -BFD_VERSION=`${srcdir}/../bfd/configure --version | sed -n -e '1s,.* ,,p'` +BFD_VERSION=`sed -n 's/AC_INIT(\[bfd\], *\[\([0-9.]*\)\])/\1/p' <${srcdir}/../bfd/configure.in`
ncopa, thanks for your findings. i can confirm that this patch http://git.proteanos.com/pkg/gdb.git/tree/patches/02_fix-opcodes-configure-bfd-version-on-busybox-ash.patch fixes the issue in gdb 7.6.2. i wonder if the new sed command in that line is not ERE conforming.
(In reply to maillist-gdb from comment #9) > i wonder if the new sed command in that line is not ERE conforming. I doubt that. I think its a bug in autoconf and I think this fixes it: http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commit;h=55f532e539427ff5829790fd71b6f8c6342b141a Which means that you should not use anything older than autoconf-2.68 to generate the tarballs.
filed https://sourceware.org/bugzilla/show_bug.cgi?id=16948 ( bug #16948 )
gdb has recently upgraded to autoconf 2.69, so according to comment #10, I believe this is fixed.