Re: configure[xxxx]: : is not an identifer
- Original Message - > From: "Paul Eggert" > To: "Kevin R. Bulgrien" , autoconf@gnu.org > Sent: Thursday, June 7, 2018 8:47:55 PM > Subject: Re: configure[]: : is not an identifer > > This looks like a known problem that we decided in 2006 not to fix > because even back then hardly anybody used OpenServer. For that old > discussion thread (which suggests some possible workarounds), please > see: > > https://lists.gnu.org/archive/html/autoconf-patches/2006-06/msg00036.html The thread even ends suggesting that people could just use bash instead: https://lists.gnu.org/archive/html/autoconf-patches/2006-06/msg00111.html Awesome catch. Thanks. Apparently I need to sharpen my search skills. -- Kevin R. Bulgrien, Network/Software Engineer Computer Systems Design, Inc dba Systems Design ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: configure[xxxx]: : is not an identifer
This looks like a known problem that we decided in 2006 not to fix because even back then hardly anybody used OpenServer. For that old discussion thread (which suggests some possible workarounds), please see: https://lists.gnu.org/archive/html/autoconf-patches/2006-06/msg00036.html ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: configure[xxxx]: : is not an identifer
- Original Message - > From: "Eric Blake" > To: "Kevin R. Bulgrien" , autoconf@gnu.org > Sent: Thursday, June 7, 2018 4:54:34 PM > Subject: Re: configure[]: : is not an identifer > > 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 found that using the last displayed value shown in the error message became unreliable near the end of the value. I ended up splitting the variable assignment into pieces of about 200 lines each to get it to work. This correlates to splitting the assignment into six pieces: $ diff -U1 configure.orig configure --- configure.orig 2018-06-06 05:41:59.0 -0500 +++ configure 2018-06-06 06:22:33.0 -0500 @@ -629,3 +629,3 @@ gl_getopt_required=POSIX -ac_subst_vars='M4tests_LTLIBOBJS +ac_subst_vars1='M4tests_LTLIBOBJS M4tests_LIBOBJS @@ -838,4 +838,4 @@ GNULIB_POSIX_SPAWNATTR_SETSIGDEFAULT -GNULIB_POSIX_SPAWNATTR_GETSIGDEFAULT -GNULIB_POSIX_SPAWNATTR_SETSCHEDPOLICY +GNULIB_POSIX_SPAWNATTR_GETSIGDEFAULT' +ac_subst_vars2='GNULIB_POSIX_SPAWNATTR_SETSCHEDPOLICY GNULIB_POSIX_SPAWNATTR_GETSCHEDPOLICY @@ -1038,4 +1038,4 @@ REPLACE_TANHF -REPLACE_TANF -REPLACE_SQRTL +REPLACE_TANF' +ac_subst_vars3='REPLACE_SQRTL REPLACE_SQRTF @@ -1239,4 +1239,4 @@ GNULIB_LOG1P -GNULIB_LOG10L -GNULIB_LOG10F +GNULIB_LOG10L' +ac_subst_vars4='GNULIB_LOG10F GNULIB_LOG10 @@ -1439,4 +1439,4 @@ UNISTD_H_HAVE_WINSOCK2_H_AND_USE_SOCKETS -UNISTD_H_HAVE_WINSOCK2_H -REPLACE_WRITE +UNISTD_H_HAVE_WINSOCK2_H' +ac_subst_vars5='REPLACE_WRITE REPLACE_USLEEP @@ -1639,4 +1639,4 @@ GNULIB_CALLOC_POSIX -GNULIB_ATOLL -GNULIB__EXIT +GNULIB_ATOLL' +ac_subst_vars6='GNULIB__EXIT LTLIBCSTACK @@ -1844,2 +1844,10 @@ SHELL' +echo $ac_subst_vars1 | wc -c >krb +echo $ac_subst_vars2 | wc -c >>krb +echo $ac_subst_vars3 | wc -c >>krb +echo $ac_subst_vars4 | wc -c >>krb +echo $ac_subst_vars5 | wc -c >>krb +echo $ac_subst_vars6 | wc -c >>krb +ac_subst_vars="$ac_subst_vars1\n$ac_subst_vars2\n$ac_subst_vars3\n$ac_subst_vars4\n$ac_subst_vars5\n$ac_subst_vars6" +echo $ac_subst_vars | wc -c >>krb ac_subst_files='' $ cat krb 4030 3609 2745 3136 3162 2540 19222 This shows the whole constructed as a sum of the parts, with the final result matching the original 19222 bytes assigned (as reported in a prior post by copying the assignment to a standalone script). With this modification, the script runs fine under this /bin/sh. If 4K is a factor in this bug, it is subtle. It has the appearance that the shell error message does not reliably show the points where the variable has to be split the further into the value you get, though I suspect the error messages occur near 4K boundaries. I first broke the value by splitting just before the last value reported by the crash, then
Re: configure[xxxx]: : is not an identifer
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
Re: configure[xxxx]: : is not an identifer
- Original Message -
> From: "Eric Blake"
> To: "Kevin R. Bulgrien" , autoconf@gnu.org
> Sent: Thursday, June 7, 2018 3:13:18 PM
> Subject: Re: configure[]: : 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
#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@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
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?
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
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
configure[xxxx]: : is not an identifer
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
I supposed that perhaps in this case, [1845] might be a line number. 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=''
The ac_subst_vars assignment is large, I wondered about command-length limits
as many years ago I ran into a situation where I found I could only write
command-line awk sources up to a certain size before source needed to be put
into a .awk file where command-line length limits were not a factor.
To that end:
$ getconf ARG_MAX
102400
But, I note that the assignment is only about 1215 lines (19238 bytes) long, so
it
hardly seems this should be the problem.
There does not appear to be a colon character anywhere nearby, so the error
message
presents somewhat of a conundrum.
Does anyone have a thought about how to begin to work through coming up with a
work
around for this sort of situation?
Apologies if this is not the most appropriate forum to ask this. I'll gladly
take
suggestions on how to better investigate the issue or provide helpful
information.
--
Kevin R. Bulgrien, Network/Software Engineer
Computer Systems Design, Inc dba Systems Design
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
