Re: configure[xxxx]: : is not an identifer

[Eric Blake]

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