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

[Eric Blake]

On 06/07/2018 02:17 PM, Kevin R. Bulgrien wrote:
> I find myself trying to build newer versions of GNU toolchain components on a 
> very
> old system, namely OpenServer 5.0.7.  I know that supporting old systems like 
> this
> is difficult, so I do recognize a need to do the heavy lifting on my own, 
> however,
> if anyone could offer some help, it would be great.
>
> I've run into the following error all too frequently, and, to avoid the error, 
> so
> far, have just backed off to an older release of whatever is being built.  For
> example:
>
>    address@hidden:~/gnu.org/m4-1.4.18]$ ./configure -C --prefix=${HOME}
>    ./configure[1845]: : is not an identifier

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?

> I supposed that perhaps in this case, [1845] might be a line number.

Or maybe a process id?

>  If that is the
> case, I suppose that this error is happening in an ac_subst_vars='' assignment.
> This assignment begins at line 630 and ends at line 1844 of the configure 
> script.
> Line 1845 contains a different, one-line assignment:  ac_subst_files=''

If it is not a line number, then knowing what the shell was executing 
right beforehand might pinpoint where the error is.  I'm suspecting that 
somewhere in the script is an instance of ':=xyz', and the shell is 
trying to interpret it as a variable assignment, except that ':' isn't a 
variable name; that may have happened if something that was supposed to 
substitute in a valid name instead ended up substituting in an empty string.

It's also possible to hack in echo statements (either to the 
configure.ac, followed by regeneration, or directly into the generated 
configure) to follow along as the script executes (sometimes, reaching, 
or failing to reach, a 'Got here' message can be great for zeroing in on 
where the problem is actually happening).  Or even turn on 'set -x' 
closer to the problem point, rather than running the entire script under 
-x, for less verbose hunting for the problem.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org