Summary: | building gdb fails when bash is not installed | ||
---|---|---|---|
Product: | gdb | Reporter: | maillist-gdb |
Component: | build | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | ncopa, sergiodj, tromey |
Priority: | P2 | ||
Version: | 7.6 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | ||
Bug Depends on: | 16948 | ||
Bug Blocks: |
Description
maillist-gdb
2013-12-26 22:20:20 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. 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. gdb has recently upgraded to autoconf 2.69, so according to comment #10, I believe this is fixed. |