This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: striking out at the eabi


I wrote:
The "eval" undoes a level of quoting; it's the only thing I could come
up with that makes passing multiple flags to --enable-cxx-flags work.

Actually, to be more precise (I think), "eval" flattens its arguments into a string and then re-tokenizes the result, evaluating shell metacharacters in the process (including one level of quotes, or possibly more given the rules for double and back quotes) -- except for shell metacharacters that are protected by the quoting rules or escaped with a backslash in the flattened string (in which case it eats the backslash and leaves the metacharacter alone). The resulting list of tokens is then passed to the command evaluation stage just as if it had been the result of tokenizing a command line in the usual fashion. The arguments to eval have of course already been through the tokenizer once (performing variable substitution and other metacharacter interpretation) before eval sees them; so my saying that eval "undoes a level of quoting" was a crude half-truth. Sorry. :-)

What drove me to exploit this is that my earm.dat contains:

GCC_EXTRA_CONFIG='--with-cpu=arm926ej-s --with-float=soft
"--enable-cxx-flags=-mcpu=arm926ej-s -msoft-float"'

When latest.sh uses "eval `cat earm.dat latest.dat` ..." to fold
variables defined in *.dat into the environment that is eventually
passed to crosstool.sh, it eats one level of quotes, including the
single quotes in the above.  What was happening to me was that when
$GCC_EXTRA_CONFIG was interpolated into the configure command line
_without_ eval, the double quotes weren't treated as shell
metacharacters; the command line got tokenized at the space between
arm926ej-s and -msoft-float, the double quotes remained attached to
the two tokens, and GCC's configure died horribly.

I'm not a shell wizard and I don't really understand why the double
quotes aren't processed after $GCC_EXTRA_CONFIG is interpolated.  The
contents of $GCC_EXTRA_CONFIG are certainly getting tokenized at
whitespace, which means that they went through the tokenizer again
sometime after the pass that ate the single quotes; why didn't that
pass interpret the double quotes as metacharacters?  I would suspect a
bug in the rather old bash on my build host (still running Red Hat 8
for hysterical reasons), except that autoconf-generated configure
scripts tend to be fairly strenuous shell stress tests and it's hard
to imagine that such a bug wouldn't break the convoluted machinery for
quoting preservation within configure.

Using "eval" to force stringification and re-tokenization seems to
work for me, and a casual inspection of the demo .dat files didn't
reveal any other attempts to pass multiple flags to
--enable-cxx-flags.  So I included that change in my patch in hopes
that others who need similar combinations of flags will try it and
either report success or failure.

In short, if it works for you, great.  If not, perhaps it's a bug in
my old bash and the workaround should stay in my private patch.

Cheers,
- Michael

--
For unsubscribe information see http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]