On 06/07/2018 04:30 PM, Kevin R. Bulgrien wrote:
Can you run under '/bin/sh -x ./configure' (or whatever shell
configure
actually picks in place of /bin/sh) to get a more verbose log right
before the failure message of what the script was attempting?
Yes, I did this after posting the original e-mail, and I got a result
that showed me the last command that ran was the ac_subst_vars
assignment:
...
+ ./configure[1845]: : is not an identifier
This is about 4K into the value being assigned.
Then it sounds like we've found a legitimate shell bug in your /bin/sh.
It would be nice to fine-tune the characteristics of the bug; is it merely:
a='8k wall of text'
that fails, while:
a='4k...'
b='4k...'
a="$a$b"
works? Or is it that a shell variable in general cannot hold more than
4k? Does the size of the shell script matter (as in the bug is present
if the assignment also coincides with some other large boundary, such as
a 64k page size)?
I found that if I broke up this value by assigning it to different
variables (so as not to reduce variable store usage), the script
runs "fine". I.e., I break up the ac_subst_vars along the lines
of:
ac_subst_vars='...
...'
foo='...
...'
bar='...
...'
Where the size of each piece is similar (~4K). When this is done,
the configure script runs "fine", though it is certainly damaged.
Well, yeah, if you break it up to get past tickling the overlarge
assignment bug, but then don't reassemble it, the resulting
substitutions are incomplete and the end product would be damaged. As
long as variables can hold more than 4k (even if we have to build it via
smaller steps), that can be worked around.
I unintentionally over-rode the #!/bin/sh in the script with:
$ bash -x ./configure -C --prefix=${HOME}
This resolved the problem, and ./configure ran fine with the
unmodified configure script.
The preferred spelling for this is:
CONFIG_SHELL=/path/to/bash ./configure CONFIG_SHELL=/path/to/bash -C...
(yes, this is the one case where you have to pass CONFIG_SHELL both in
the environment and on the command line; it's a bit of a boot-strapping
dilemma for forcing the configure script to choose a given shell rather
than its normal behavior of choosing a best shell).
The system /bin/sh does not report version, but can be loosely
identified in the OpenServer ecosystem:
$ ls -l /bin/sh
lrwxrwxrwx 1 root root 30 May 5 2008 /bin/sh -> /opt/K/SCO/Unix/5.0.7Hw/bin/sh
Old, but the real question is if it is still part of a supported distro
(in which case it would be really nice to work around it) or if the
vendor has long since dropped support (in which case it's probably not
worth spending time on something even the vendor doesn't care about)
I do have BASH built for this system:
Does bash (or any other shell flavors) come pre-installed, or does a
pristine system come with only the broken /bin/sh? (Again, the
bootstrapping question, of whether it is merely sufficient to detect the
/bin/sh bug and avoid it altogether because we should always be able to
find something else, or whether we should try hard to work in spite of
the /bin/sh bug because bash won't always be found). Obviously, it's
worked for you to install bash, and if nothing else, we can always
recommend that a user with a broken /bin/sh install bash, but that feels
like a fallback solution (and may not work if bash itself can't be
self-built because it has a configure script that also tickles the bug).
$ bash --version
GNU bash, version 4.3.30(1)-release (i586-pc-sco3.2v5.0)
I supposed that perhaps in this case, [1845] might be a line
number.
Or maybe a process id?
Based on using /bin/sh -x to invoke the configure script, it is clear
that [1845] is a line number.
It seems clear the OpenServer 5.0.7 system /bin/sh shell is inadequate in
some way, but it also seems clear that it is not a simple matter of
variable length. If, using vim, I create my own script with #!/bin/sh, I
can copy the ac_subst_vars assignment into it and it works just fine, and,
besides, I can create variables with much larger values in this shell.
#!/bin/sh
ac_subst_vars='...
...
...'
echo "${ac_subst_vars}" | wc -c
./test.sh
19222
Oh well, that's going to make characterizing the bug even harder :(
You've identified the size of the assignment statement, and the line it
starts on; can you also identify the text near various 4k points in the
generated configure file lie, to see if something syntactically
interesting is happening if the shell treats two separate parts of a
line in an interesting manner? (For example, splitting 'ab=cd' into 'a'
and 'b=cd' has different semantic than splitting into 'ab' and '=cd';
and the error message about an empty variable name being an invalid
assignment might be a case of splitting right before the =).
Any thought as to whether I should I just move along and recognize I
need to use BASH in these cases, or is this an indication of
something to address somewhere in the tool chain that does
not detect this problem?
Knowing that bash is a workaround is good; so now it's a question of
whether it's also worth trying to spend effort on making autoconf
smarter to avoid this problem with /bin/sh for other users of your
platform, or whether your situation is niche enough that we just let you
live with the workaround.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
