Bug 16370 - building gdb fails when bash is not installed
Summary: building gdb fails when bash is not installed
Alias: None
Product: gdb
Classification: Unclassified
Component: build (show other bugs)
Version: 7.6
: P2 critical
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on: 16948
  Show dependency treegraph
Reported: 2013-12-26 22:20 UTC by maillist-gdb
Modified: 2018-08-07 22:57 UTC (History)
3 users (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description maillist-gdb 2013-12-26 22:20:20 UTC
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):

+ echo XXX ${srcdir}/configure.host XXX > /dev/tty
 # Permit host specific settings.
 . ${srcdir}/configure.host

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" \
../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
Comment 1 maillist-gdb 2013-12-27 00:46:04 UTC
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.
Comment 2 Sergio Durigan Junior 2013-12-27 20:25:57 UTC
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?
Comment 3 maillist-gdb 2014-03-21 01:58:00 UTC
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 :/
Comment 4 Sergio Durigan Junior 2014-03-21 03:44:13 UTC
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.
Comment 5 ncopa 2014-05-05 11:19:08 UTC
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.
Comment 6 ncopa 2014-05-06 06:20:21 UTC
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.
Comment 7 ncopa 2014-05-06 07:07:51 UTC
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.

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).
Comment 8 ncopa 2014-05-06 15:02:58 UTC
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`
Comment 9 maillist-gdb 2014-05-12 13:57:18 UTC
ncopa, thanks for your findings.
i can confirm that this patch
fixes the issue in gdb 7.6.2.
i wonder if the new sed command in that line is not ERE conforming.
Comment 10 ncopa 2014-05-15 11:22:09 UTC
(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:


Which means that you should not use anything older than autoconf-2.68 to generate the tarballs.
Comment 11 maillist-gdb 2014-05-15 15:51:31 UTC
filed https://sourceware.org/bugzilla/show_bug.cgi?id=16948 ( bug #16948 )
Comment 12 Tom Tromey 2018-08-07 22:57:24 UTC
gdb has recently upgraded to autoconf 2.69, so according to comment #10,
I believe this is fixed.