| Summary: | dev-libs/apr with non-bash shell - /usr/share/build-1/libtool: 1: eval: base_compile+= x86_64-pc-linux-gnu-gcc: not found | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Maciej Piechotka <uzytkownik2> |
| Component: | [OLD] Library | Assignee: | Apache Team - Bugzilla Reports <apache-bugs> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | alexander, jer, mgorny, nikoli |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=526178 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 526268 | ||
| Attachments: | app-admin:apache-tools-2.4.12:20150214-222314.log.gz | ||
|
Description
Maciej Piechotka
2015-02-15 06:42:38 UTC
Please post your `emerge -vpq dev-libs/apr' output in a comment. (In reply to Jeroen Roovers from comment #1) > Please post your `emerge -vpq dev-libs/apr' output in a comment. [ebuild R ] dev-libs/apr-1.5.1-r1 USE="urandom -doc -older-kernels-compatibility -static-libs" What I don't get is why it has the appropriate shebang pointing to /bin/bash, but *your* system manages to run that through /bin/dash anyway. If you happen to have a /bin/bash -> dash symlink or similar, then this bug report should be considered INVALID. (In reply to Jeroen Roovers from comment #3) > What I don't get is why it has the appropriate shebang pointing to > /bin/bash, but *your* system manages to run that through /bin/dash anyway. > If you happen to have a /bin/bash -> dash symlink or similar, then this bug > report should be considered INVALID. I switch the shell via eselect so had the /bin/bash do point to dash it's not my fault. When I switch to bash via eselect it works. % ls -l /bin/bash /bin/dash /bin/sh -rwxr-xr-x 1 root root 726040 Jan 23 21:09 /bin/bash -rwxr-xr-x 1 root root 109856 Oct 16 09:15 /bin/dash lrwxrwxrwx 1 root root 4 Feb 14 22:37 /bin/sh -> dash % /bin/bash --version GNU bash, version 4.3.33(1)-release (x86_64-pc-linux-gnu) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software; you are free to change and redi (In reply to Maciej Piechotka from comment #4) > (In reply to Jeroen Roovers from comment #3) > > What I don't get is why it has the appropriate shebang pointing to > > /bin/bash, but *your* system manages to run that through /bin/dash anyway. > > If you happen to have a /bin/bash -> dash symlink or similar, then this bug > > report should be considered INVALID. > > I switch the shell via eselect so had the /bin/bash do point to dash it's > not my fault. When I switch to bash via eselect it works. Um, not as far as I am aware. sh.eselect handles the /bin/sh -> symlink and never sets a /bin/bash symlink target. It may set a /bin/sh -> bash target, but that's different. I'm CC-ing mgorny for confirmation so that we may know. I've got the same problem building apache-tools. My /bin/sh is a symlink to /bin/dash. The actual command that fails is: /usr/share/build-1/libtool --silent --mode=compile x86_64-pc-linux-gnu-gcc -pthread -march=nocona -O2 -pipe -DLINUX -D_REENTRANT -D_GNU_SOURCE -I. -I/var/tmp/portage/app-admin/apache-tools-2.2.29/work/httpd-2.2.29/os/unix -I/var/tmp/portage/app-admin/apache-tools-2.2.29/work/httpd-2.2.29/server/mpm/prefork -I/var/tmp/portage/app-admin/apache-tools-2.2.29/work/httpd-2.2.29/modules/http -I/var/tmp/portage/app-admin/apache-tools-2.2.29/work/httpd-2.2.29/modules/filters -I/var/tmp/portage/app-admin/apache-tools-2.2.29/work/httpd-2.2.29/modules/proxy -I/var/tmp/portage/app-admin/apache-tools-2.2.29/work/httpd-2.2.29/include -I/var/tmp/portage/app-admin/apache-tools-2.2.29/work/httpd-2.2.29/modules/generators -I/var/tmp/portage/app-admin/apache-tools-2.2.29/work/httpd-2.2.29/modules/mappers -I/var/tmp/portage/app-admin/apache-tools-2.2.29/work/httpd-2.2.29/modules/database -I/usr/include/apr-1 -I/usr/include/db4.8 -I/var/tmp/portage/app-admin/apache-tools-2.2.29/work/httpd-2.2.29/modules/proxy/../generators -I/usr/include -I/usr/kerberos/include -I/var/tmp/portage/app-admin/apache-tools-2.2.29/work/httpd-2.2.29/modules/ssl -I/var/tmp/portage/app-admin/apache-tools-2.2.29/work/httpd-2.2.29/modules/dav/main -prefer-non-pic -static -c htpasswd.c && touch htpasswd.lo It works if I run it with bash. /bin/bash /usr/share/build-1/libtool [...] The libtool script abve comes from dev-libs/apr-1.5.0-r2 in my case. The shebang in the script points to /bin/sh. You can rebuild apr as a workaround - shebang will be changed to /bin/bash. And I think this bug is a duplicate of bug 528798 Using pre-generated libtool is just plain broken. That file should be banned immediately. Unfortunately every package which DEPEND on apr use this pre-generated libtool. =/ Then every package needs to be fixed. This libtool can get out of sync and break at any random point in time if anything in ebuild environment changes. I'm seeing build failures with: libtool: Version mismatch error. This is libtool 2.4.6, but the libtool: definition of this LT_INIT comes from libtool 2.4.2. libtool: You should recreate aclocal.m4 with macros from libtool 2.4.6 libtool: and run autoconf again. ... when trying to build apr on a prefix install - does this look like the same issue (e.g. bundled libtool is now out of sync)? Sorry, meant to mention that this was against dev-libs/apr-1.5.2 (In reply to Stuart Shelton from comment #11) > I'm seeing build failures with: > > libtool: Version mismatch error. This is libtool 2.4.6, but the > libtool: definition of this LT_INIT comes from libtool 2.4.2. > libtool: You should recreate aclocal.m4 with macros from libtool 2.4.6 > libtool: and run autoconf again. > > ... when trying to build apr on a prefix install - does this look like the > same issue (e.g. bundled libtool is now out of sync)? |
