| Summary: | x11-terms/xterm >=app-shells/dash-0.5.8.1-r2 fails with /bin/sh -> dash | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Lars Wendler (Polynomial-C) (RETIRED) <polynomial-c> |
| Component: | Current packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | alexander, base-system, bugs+gentoo, dickey, jcallen, jstein |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 526268 | ||
| Attachments: |
build.log
xterm-304.ebuild.patch xterm-312.ebuild.patch |
||
|
Description
Lars Wendler (Polynomial-C) (RETIRED)
2014-11-30 17:06:40 UTC
In a quick check, I don't see a problem on Debian (which uses dash). Perhaps there's a locale-related issue for instance with a punctuation character in the sed-command. The sed command is operating on 48-line chunks of a longer sed-script; the reference to "subs-1" seems to be the first chunk (in config.status). In the check I ran, that is this line: s,@PATH_SEPARATOR@,:,;t t (which may/may not be the same as your build. But verifying that might help - also knowing what the locale settings are. I can't reproduce this, it might be a problem on your end.
$ readlink /bin/sh
dash
$ cd /usr/portage/x11-terms/xterm
$ sudo ebuild xterm-312.ebuild unpack prepare configure
[snip]
configure: creating ./config.status
config.status: creating Makefile
config.status: creating df-install
config.status: creating minstall
config.status: creating xtermcfg.h
>>> Source configured.
This bug is only reproducible with dash-0.5.8.1-r2, where echo doesn't support '-n' option. vm3020 xterm-304 # grep ac_cv_have_x config.log ac_cv_have_x='have_x=yes ac_x_includes= ac_x_libraries=/usr/lib64' dash-0.5.8.1 vs dash-0.5.8.1-r2:
s,@target_alias@,,;t t
-s,@ECHO_C@,\c,;t t
+s,@ECHO_C@,
+,;t t
s,@ECHO_N@,,;t t
Looks like the real problem is that configure is generated with old autoconf 2.52.20121002 and it have a strange check for echo options. eautoreconf fails because macro AC_DIVERT_HELP is only defined in aclocal.m4 shipped with xterm:
configure:6428: error: possibly undefined macro: AC_DIVERT_HELP
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
If there's a problem running the unmodified configure script, I'm interested in that. For regenerating the configure script, see http://invisible-island.net/autoconf/autoconf.html configure script is generated with patched autoconf [1]. AC_DIVERT_HELP macro defined only in patched acgeneral.m4 and definition for that macro is not shipped with xterm. [1] ftp://invisible-island.net/autoconf/autoconf-2.12-971230.patch.gz (In reply to Alexander Tsoy from comment #6) > macro AC_DIVERT_HELP is only defined in aclocal.m4 shipped with xterm: That's not correct. As I mentioned in previous comment, it is defined in patched acgeneral.m4 :( A "2.12" patch cannot possibly be current. This is current, as noted on the webpage: http://invisible-island.net/datafiles/release/autoconf.tar.gz Created attachment 390698 [details, diff]
xterm-304.ebuild.patch
The attached patch fixes this bug. I've tested it with xterm-304 and -312.
Created attachment 390702 [details, diff]
xterm-312.ebuild.patch
Cleanup sed script.
(In reply to Alexander Tsoy from comment #3) Indeed, I can reproduce this bug with the new version of dash. (In reply to Alexander Tsoy from comment #12) This patch works for me. I tested it on xterm-297, -304 and -312. Question is, is it appropriate? On one hand, the delay in src_prepare() is negligable: $ sudo ebuild xterm-312.ebuild unpack [snip] $ time sudo ebuild xterm-312.ebuild prepare >>> Existing ${T}/environment for 'xterm-312' will be sourced. [snip] real 0m5.975s user 0m5.460s sys 0m0.380s On the other hand, it prints an ugly warning message. I say wait for upstream to put out a new release. A copy of the relevant config.status and config.log would be helpful. I do not know how to reproduce this; installing Gentoo isn't a solution. (In reply to Andrew Miller from comment #13) I've attached a patch just to prove that it's an autoconf's fault. > On the other hand, it prints an ugly warning message. It's a QA warning recently added to autotools.eclass and is easy fixable: mv configure.{in,ac} || die (In reply to Thomas Dickey from comment #14) See patch [1] which was applied to dash-0.5.8.1-r2 in Gentoo. It changes echo behavior as follows: - disable interpretation of escape sequences; - drop support for '-n' option. So the following shell code doesn't work in any way with that version of dash (and it is really not portable): echo $ECHO_N "Some text $ECHO_C" autoconf >=2.62 uses AS_ECHO macro which works fine. [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-shells/dash/files/dash-0.5.8.1-dumb-echo.patch?view=markup (In reply to Thomas Dickey from comment #14) You need a shell which doesn't support 'echo -n', like dash-0.5.8.1-r2, which is a Gentoo-specific version of dash. Note the '-r2' suffix, which signifies a change made in Gentoo, not an upstream change. The vast majority of shells do support 'echo -n', which is why this bug hasn't been discovered until now. On Debian, you could try this: 1. tar xzvf xterm-312.tgz 2. cd xterm-312/ 3. emacs -nw 4. type alt-x, type eshell, press return 5. ./configure I think we have two options to close this bug: 1. Apply the patch in comment #12 and workaround the warning message that is printed. 2. You could put out minor revisions of xterm-297, -304 and -312, that have configure scripts generated by a recent version of autoconf. There were two choices suggested; one was specific to Gentoo, the other was specific to me (so that was not offering a choice). I already had a to-do item to cleanup a warning message for Solaris. From the discussion, it appears that Gentoo prefers the Solaris behavior, so any upstream changes to xterm would necessarily reference Solaris. If I understand comment #15 and comment #16 correctly, the problem happens with any shell that does not support "echo -n" (e.g. Gentoo patched dash) and is fixed by generating configure with autoconf-2.62 or later. In that case it appears preferable to upgrade the autoconf version that is used to generate configure. hmm - comment 6 shows the fragment I was looking for (had not noticed before). At first glance, it seemed that the "fix" was to suppress the newline in the substitution for ECHO_C. However, checking the standard at http://pubs.opengroup.org/onlinepubs/009695399/utilities/echo.html I see that the actual problem is that the patch made to dash is defective. The patch removes nonl += conv_escape_str(*argv); which provides the functionality described as "The following character sequences shall be recognized on XSI-conformant systems within any of the arguments:". The remaining call to outstr() does not provide this functionality. It is lost. Because the patched dash fails to follow the standard in this area, the script falls through into the obscure case noted. autoconf uses the echo/whatever feature only in 2 places, and in neither is the feature actually necessary (empty strings would suffice). A standard-conforming shell would give that behavior. (What I'm left with is my original to-do item; there's nothing here that needs any of my attention). CC'ing dash maintainers (In reply to Thomas Dickey from comment #19) not really. the XSI extensions are just that -- extensions. we disabled said extensions in dash because they cause more problems than they're worth, and relying on them is not portable. plus, if you read the spec closer, you'll see the choices are one of two: (1) -n/escape sequences are implementation defined (i.e. not portable, and the dash change disables those entirely) (2) XSI compliant where -n is a string, not an option, and you get escape sequences. so an XSI compliant system would do: `echo -n foo | hexdump -C` -> 2d 6e 20 66 6f 6f 0a `echo -n \t\n | hexdump -C` -> 2d 6e 20 09 0a you cannot rely on an implementation supporting both escape sequences and the -n option. dash & bash already diverge here -- dash supports -n & escape (which means it is *not* XSI compliant, but it does fall into the "implementation defined" area), while bash requires the -e flag. simply use `printf` if you want to be portable and have escape sequences. are you still hitting this with 331? Seems to be no longer an issue. |