Summary: | media-libs/sdl-mixer fails to build with /bin/sh set to dash | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ilya Trukhanov <lahvuun> |
Component: | Current packages | Assignee: | Gentoo Games <games> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | alexander, jstein, kfm |
Priority: | Normal | Keywords: | PullRequest |
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
See Also: | https://github.com/gentoo/gentoo/pull/16197 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 526268 | ||
Attachments: |
output of `emerge -pqv '=media-libs/sdl-mixer-1.2.12-r4::gentoo'`
complete build.log complete build.log with CONFIG_SHELL=/bin/bash |
Description
Ilya Trukhanov
2020-04-29 19:26:07 UTC
Created attachment 635228 [details]
complete build.log
Created attachment 635242 [details] complete build.log with CONFIG_SHELL=/bin/bash I believe this is related to https://bugs.gentoo.org/714094 When I set CONFIG_SHELL=/bin/bash through /etc/portage/env/ as suggested in the bug report, make gets further but eventually breaks with a bunch of libtool errors. Build log with CONFIG_SHELL=/bin/bash attached. I think these are also related to /bin/sh being set to dash. I managed to get the package to build succesfully by adding the following function to the ebuild: multilib_src_compile() { emake SHELL=${BASH} } Ilya, have you tried to install it using dash-0.5.11? Looks like a bug in dash, which is fixed in 0.5.11. If so, I don't think it is a right thing to add this workaround here. You may want to create a bug for stabilizing 0.5.11. `equery l dash` returns `app-shells/dash-0.5.11:0`, build still fails with the same errors with `/bin/sh -> dash`. Actually, I think I figured it out. There's the following line in the `configure` output: `checking whether the shell understands "+="...` When building manually (not with portage), this check results in "no". When building with portage, it results in "yes". I checked portage's source code for the `econf` function, and I believe I located it in `bin/phase-helpers.sh`. Looks like it checks if the `CONFIG_SHELL` variable is set, and replaces occurrences of "/bin/sh" with "#!$CONFIG_SHELL" in the `configure` file. I then added `echo "CONFIG_SHELL is $CONFIG_SHELL"` to the beginning of the `multilib_src_configure` function in `sdl-mixer-1.2.12-r4.ebuild`. When building the package with portage, before the configure script runs I get "CONFIG_SHELL is /bin/bash". So, it seems to me that portage for some reason sets `CONFIG_SHELL` to `/bin/bash`, then the `configure` script has its shebang (`#! /bin/sh) replaced with `#!/bin/bash`. The script then executes under bash, correctly infers that bash understands "+=" and outputs this operation in the resulting build scripts, which then get invoked with `/bin/sh` for some reason. Dash, not understanding "+=", explodes, taking the build down with it. I don't think it's possible to send a patch upstream (the last release was in 2012) and I'm not even sure that this is an upstream issue since it looks like it's the portage's modification of the shebang that causes this. Maybe it's possible to get portage to not set `CONFIG_SHELL` somehow? It'd be nice if we could get maybe someone from the portage team to look at this and figure out the best course of action. (In reply to Ilya Trukhanov from comment #4) > I then added `echo "CONFIG_SHELL is $CONFIG_SHELL"` to the beginning of the > `multilib_src_configure` function in `sdl-mixer-1.2.12-r4.ebuild`. When > building the package with portage, before the configure script runs I get > "CONFIG_SHELL is /bin/bash". I can't reproduce this. Certainly, ebuild authors are able to define CONFIG_SHELL if they so choose, in which case phase-helpers.sh does alter the shebang of the configure script in the manner that you describe. However, CONFIG_SHELL is not set by default, nor does the sdl-mixer ebuild define it. Please remove any declarations of CONFIG_SHELL from your operating environment, be it by way of /etc/portage/env, /etc/portage/bashrc, your shell dotfiles or any other mechanism, then try building again with >=dash-0.5.11 as /bin/sh. There should not be an issue at this point in time. Also, please check whether any of the third-party repos (overlays) that you are using have eclass overrides in effect and whether they might be interfering with the default environment. This just isn't an issue any more because the affected version of dash has been removed. Closing. |