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

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

[david.hagood]

>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.

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

[Alan Modra]

On Mon, Feb 06, 2012 at 08:54:20AM -0600, david.hagood@gmail.com wrote:
> Since that variable is binutils, I am on this list.

Andreas kindly pointed you at the glibc Makerules file.  If you had
looked instead of whining you would have found a couple of lines in
that file:
		 PROVIDE(__start___libc_subfreeres = .);\
		 __libc_subfreeres : { *(__libc_subfreeres) }\

which more or less match your make output:

                 PROVIDE(__start__es : {subfreeres = .);\
                 __libc_subfreeres : { *(__libc_subfreeres) }\

Except somehow the string "_libc_" on the first line has been replaced
by "es : {".  That's hardly likely to be due to a binutils gremlin.

As to why your toolchain builds with binutils-2.20 but not with
binutils-2.22, it is likely some glibc configure test detecting ld
features, enabling different make rules or parts thereof.  There's one
right in the rule I partially quote above.

-- 
Alan Modra
Australia Development Lab, IBM

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

[david.hagood]

You might actually READ my posting:

"
I have no idea where that is coming from: it's not in any of the makefiles
for binutils, glibc, or gcc, it's not in my host toolchain - and it
doesn't happen on PPC."

As in, no make file, no tool, nothing contains that line. So why Make is
putting it into the runtime is not clear. Yes, I can SEE that the command
line to sed contains that line - but WHY it contains that is not clear, as
it does not appear in the make file, nor in any of the tools.

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

[Andreas Schwab]

The line is coming literally from the Makerules file.

In any way, this has nothing to do with bintuils.  You need to fix the
sed command not to put the erroneous line there.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[David Hagood]

On Sat, 2012-02-04 at 00:02 +0100, Andreas Schwab wrote:
> The line is coming literally from the Makerules file.
> 
> In any way, this has nothing to do with bintuils.  You need to fix the
> sed command not to put the erroneous line there.
> 
> Andreas.
> 
Did you miss the part in my first post, the bit I quoted in my second
post, the bit where I said "I have no idea where that is coming from:
it's not in any of the makefiles
for binutils, glibc, or gcc"

That includes ALL the files that drive make, including Makerules.
Please, give me credit for some sense - were the problem in Makerules, I
would have fixed it and moved on.

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

[Andreas Schwab]

David Hagood <david.hagood@gmail.com> writes:

> Did you miss the part in my first post,
> the bit I quoted in my second
> post, the bit where I said "I have no idea where that is coming from:
> it's not in any of the makefiles
> for binutils, glibc, or gcc"

That's exactly what you have to find out.  It is absolutely obvious that
this has nothing to do with binutils, because the erroneous line was
explicitly written into linker script.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[David Hagood]

On Sat, 2012-02-04 at 09:00 +0100, Andreas Schwab wrote:
> That's exactly what you have to find out.  It is absolutely obvious that
> this has nothing to do with binutils, because the erroneous line was
> explicitly written into linker script.
Except you seem to have missed the bit in my first post that this only
started happening AFTER I replaced the older version of binutils I was
cross-compiling with the newer version of binutils - that is, when I
stopped building binutils-2.20 for the cross environment and started
building binutils-2.22 for the cross environment. Now, I know that "post
hoc, ergo propter hoc" is a fallacy, but to start checking the
assumption that the thing I changed might have something to do with the
change is not unreasonable.

Look: if you don't want to help me, fine. Stop replying to my mails. But
I am seeing this. I am not the only one seeing this. I am pursuing this
on both the binutils board (because changing binutils seems to be what
precipitated the change) and on the libc board.

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

[Andreas Schwab]

David Hagood <david.hagood@gmail.com> writes:

> Except you seem to have missed the bit in my first post that this only
> started happening AFTER I replaced the older version of binutils I was
> cross-compiling with the newer version of binutils

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

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Weird error cross-compiling glibc with binutils 2.22 or head

[david.hagood]

I am building a cross compile environment for ARM, PPC, and X86, and due
to the other issues discussed on the list, I am trying to do it with
binutils 2.22 (and binutils head, no change).

The issue is that when building glibc for the ARM (but, curiously, NOT for
the PPC - same tools, same commands, just a different target arch) I get
an error in the compile of glibc:
arm-linux-gnueabi-gcc   -nostdlib -nostartfiles -r -o
Build/arm-linux-gnueabi/glibc_main/libc_pic.os \
         -Wl,-d -Wl,--whole-archive
Build/arm-linux-gnueabi/glibc_main/libc_pic.a
arm-linux-gnueabi-gcc   -shared -Wl,-O1 \
                  -nostdlib -nostartfiles \
                   -Wl,-dynamic-linker=/lib/ld-linux.so.3 -Wl,-z,combreloc
-Wl,-z,relro
-Wl,--hash-style=both \
                  -Wl,--verbose 2>&1 | \
          sed > Build/arm-linux-gnueabi/glibc_main/shlib.ldsT \
              -e '/^=========/,/^=========/!d;/^=========/d' \
               -e 's/^.*\.gnu\.hash[         ]*:.*$/  .note.ABI-tag : {
*(.note.ABI-tag)
} &/' -e '/^[         ]*\.hash[         ]*:.*$/{h;d;}' -e
'/DATA_SEGMENT_ALIGN/{H;g}'  \
              -e 's/^.*\*(\.dynbss).*$/& \
                 PROVIDE(__start___libc_freeres_ptrs = .); \
                 *(__libc_freeres_ptrs) \
                 PROVIDE(__stop___libc_freeres_ptrs = .);/'\
              -e 's@^.*\*(\.jcr).*$@& \
                 PROVIDE(__start__es : {subfreeres = .);\
                 __libc_subfreeres : { *(__libc_subfreeres) }\
                 PROVIDE(__stop___libc_subfreeres = .);\
                 PROVIDE(__start___libc_atexit = .);\
                 __libc_atexit : { *(__libc_atexit) }\
                 PROVIDE(__stop___libc_atexit = .);\
                 PROVIDE(__start___libc_thread_subfreeres = .);\
                 __libc_thread_subfreeres : { *(__libc_thread_subfreeres) }\
                 PROVIDE(__stop___libc_thread_subfreeres = .);\
                 /DISCARD/ : { *(.gnu.glibc-stub.*) }@'
mv -f Build/arm-linux-gnueabi/glibc_main/shlib.ldsT
Build/arm-linux-gnueabi/glibc_main/shlib.lds
<snip a buch of items>
Build/arm-linux-gnueabi/glibc_main/elf/ld.so -lgcc
ld:Build/arm-linux-gnueabi/glibc_main/shlib.lds:149: syntax error

The error is:
         PROVIDE(__start__es : {subfreeres = .);
(note the unbalanced { and ))

I have no idea where that is coming from: it's not in any of the makefiles
for binutils, glibc, or gcc, it's not in my host toolchain - and it
doesn't happen on PPC.

I've search the web, and found files in pastebin with the same error,
dating just a couple of days ago, but no references to those files on
either binutils, glibc, or GCC's mailing lists.

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

[Andreas Schwab]

david.hagood@gmail.com writes:

>           sed > Build/arm-linux-gnueabi/glibc_main/shlib.ldsT \
>               -e '/^=========/,/^=========/!d;/^=========/d' \
>                -e 's/^.*\.gnu\.hash[         ]*:.*$/  .note.ABI-tag : {
> *(.note.ABI-tag)
> } &/' -e '/^[         ]*\.hash[         ]*:.*$/{h;d;}' -e
> '/DATA_SEGMENT_ALIGN/{H;g}'  \
>               -e 's/^.*\*(\.dynbss).*$/& \
>                  PROVIDE(__start___libc_freeres_ptrs = .); \
>                  *(__libc_freeres_ptrs) \
>                  PROVIDE(__stop___libc_freeres_ptrs = .);/'\
>               -e 's@^.*\*(\.jcr).*$@& \
>                  PROVIDE(__start__es : {subfreeres = .);\

Here ----------------^

>                  __libc_subfreeres : { *(__libc_subfreeres) }\
>                  PROVIDE(__stop___libc_subfreeres = .);\
>                  PROVIDE(__start___libc_atexit = .);\
>                  __libc_atexit : { *(__libc_atexit) }\
>                  PROVIDE(__stop___libc_atexit = .);\
>                  PROVIDE(__start___libc_thread_subfreeres = .);\
>                  __libc_thread_subfreeres : { *(__libc_thread_subfreeres) }\
>                  PROVIDE(__stop___libc_thread_subfreeres = .);\
>                  /DISCARD/ : { *(.gnu.glibc-stub.*) }@'
> mv -f Build/arm-linux-gnueabi/glibc_main/shlib.ldsT
> Build/arm-linux-gnueabi/glibc_main/shlib.lds
> <snip a buch of items>
> Build/arm-linux-gnueabi/glibc_main/elf/ld.so -lgcc
> ld:Build/arm-linux-gnueabi/glibc_main/shlib.lds:149: syntax error
>
> The error is:
>          PROVIDE(__start__es : {subfreeres = .);
> (note the unbalanced { and ))
>
> I have no idea where that is coming from:

See above.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[John Reiser]

> I have no idea where that is coming from: it's not in any of the makefiles
> for binutils, glibc, or gcc, it's not in my host toolchain - and it
> doesn't happen on PPC.

Could it be part of the default linker script?
   $ ld --verbose  <linker_flags_but_no_filenames>  > default_script.lds
Look in default_script.lds.

If not in the default linker script, then apply the "biggest hammer":
   $ strace -f -o strace.out -e trace=open <<failing_command_and_args>>
Look at strace.out to see the complete list of files that were open()ed.
The text _must_ be in one of those files, so apply 'grep', etc.
Other arguments to strace might help, too.  See the manual page, particularly
"-s strsize -e trace=read".

--