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

[Kevin R. Bulgrien]

----- Original Message -----
> From: "Eric Blake" <address@hidden>
> To: "Kevin R. Bulgrien" <address@hidden>, address@hidden
> Sent: Thursday, June 7, 2018 3:13:18 PM
> Subject: Re: configure[xxxx]: : is not an identifer
> 
> 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?

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:

  ...
  #ifdef HAVE_UNISTD_H
  # include <unistd.h>
  #endif
  + gl_use_threads_default=
  + ac_func_list=
  + ac_header_list=
  + gl_getopt_required=POSIX
  + gl_getopt_required=POSIX
  + ac_subst_vars=M4tests_LTLIBOBJS
  ...
  HAVE_POSIX_SPAWN
  GNULIB_POSIX_SPAWNATTR_DESTROY
  GNULIB_POSIX_SPAWNATTR_SETSIGMASK
  GNULIB_POSIX_SPAWNATTR_GETSIGMASK
  GNULIB_POSIX_SPAWNATTR_SETSIGDEFAULT
  GNULIB_POSIX_SPAWNATTR_GETSIGDEFAULT
  GNULIB_POSIX_SPAWNATTR_SETSCHEDPOLICY
  GNU
  + ./configure[1845]: : is not an identifier

This is about 4K into the value being assigned.

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.

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 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

I do have BASH built for this system:

$ 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

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?

-- 
Kevin R. Bulgrien, Network/Software Engineer
Computer Systems Design, Inc dba Systems Design