----- Original Message -----
> From: "Eric Blake" <eblake@xxxxxxxxxx>
> To: "Kevin R. Bulgrien" <kevinb@xxxxxxxxxxxxxxxxxxxx>, autoconf@xxxxxxx
> 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:
> >
> > [kevinb@sddemokb:~/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
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
