Kevin R. Bulgrien
2018-06-07 21:30:25 UTC
----- Original Message -----
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)
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?
Sent: Thursday, June 7, 2018 3:13:18 PM
Subject: Re: configure[xxxx]: : is not an identifer
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 resultSubject: Re: 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
--prefix=${HOME}
./configure[1845]: : is not an identifier
Can you run under '/bin/sh -x ./configure' (or whatever shellcomponents 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
--prefix=${HOME}
./configure[1845]: : is not an identifier
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?
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?number.
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
Kevin R. Bulgrien, Network/Software Engineer
Computer Systems Design, Inc dba Systems Design