Re: Weird error cross-compiling glibc with binutils 2.22 or head

[david dot hagood at gmail dot com]

>What else did you change in the mean time?  There is absolutely nothing
of binutils involved when constructing the sed command.

OK, let's start with the assumption that I am actually trying to follow
ESR's "How to ask questions the smart way", and that I am doing my
homework before coming to the list - if for no other reason than that I
want to resolve my problem as quickly as possible, and waiting on the list
is not conducive to that.

Now, the question of "what else did you change" is a fair question. Let me
put it like this:

I can change which version of binutils I build as my cross-compiler tool
chain to 2.20, and it builds. I change which version of binutils I build
as my cross compiler tool chain to 2.22, and it breaks. That is ONE LINE
in ONE MAKEFILE, which changes which tarball I unpack for the binutils
sources. Nothing else - not my host compiler tool chain, not my host
environment - changes. Yet, making that one change breaks the build.

Now again, I realize that "post hoc" does not always mean "propter hoc",
but when you change only one variable and the outcome changes, it is not
unreasonable to suspect that variable is the key, and to pursue that.
Since that variable is binutils, I am on this list.

John: Thanks for a constructive suggestion. I've looked at both my native
ld and the cross-ld. Neither contains the faulty line. And to recap:
neither does ANY file in the build process - not Makerules, not Makefile,
indeed NO FILE other than the generated linker script contains
"__start__es" or "{subfreeres = .);" - confirmed by grepping the whole
source and build tree. Nor are those strings anywhere in my native tool
chain.