Fedora kernel list - Feb 2008 - Fedora kernel build failure: *** ERROR: same build ID in nonidentical files!

Could this be yet another problem caused by the switch to GCC 4.3?

http://koji.fedoraproject.org/koji/getfile?taskID=389458&name=build.log

+ /usr/lib/rpm/find-debuginfo.sh --strict-build-id -p
''/.*/2.6.24-14.fc9(-ppc)?/.*|/.*2.6.24-14.fc9'' -o
debuginfo.list -p
''/.*/2.6.24-14.fc9-?smp(-ppc)?/.*|/.*2.6.24-14.fc9smp'' -o
debuginfosmp.list -p
''/.*/2.6.24-14.fc9-?PAE(-ppc)?/.*|/.*2.6.24-14.fc9PAE'' -o
debuginfoPAE.list -p
''/.*/2.6.24-14.fc9-?PAEdebug(-ppc)?/.*|/.*2.6.24-14.fc9PAEdebug''
-o debuginfoPAEdebug.list -p
''/.*/2.6.24-14.fc9-?debug(-ppc)?/.*|/.*2.6.24-14.fc9debug'' -o
debuginfodebug.list -p
''/.*/2.6.24-14.fc9-?xen(-ppc)?/.*|/.*2.6.24-14.fc9xen'' -o
debuginfoxen.list -p
''/.*/2.6.24-14.fc9-?kdump(-ppc)?/.*|/.*2.6.24-14.fc9kdump'' -o
debuginfokdump.list /builddir/build/BUILD/kernel-2.6.24
extracting debug info from
/var/tmp/kernel-2.6.24-14.fc9-root-ppc/boot/vmlinuz-2.6.24-14.fc9
extracting debug info from
/var/tmp/kernel-2.6.24-14.fc9-root-ppc/boot/vmlinuz-2.6.24-14.fc9smp
extracting debug info from
/var/tmp/kernel-2.6.24-14.fc9-root-ppc/usr/lib/debug/lib/modules/2.6.24-14.fc9/vmlinux
*** ERROR: same build ID in nonidentical files!
        /usr/lib/debug/lib/modules/2.6.24-14.fc9/vmlinux
   and  /boot/vmlinuz-2.6.24-14.fc9
error: Bad exit status from /var/tmp/rpm-tmp.98614 (%install)

On 02/01/2008 02:00 PM, Chuck Ebbert wrote:
> Could this be yet another problem caused by the switch to GCC 4.3?
> 
> http://koji.fedoraproject.org/koji/getfile?taskID=389458&name=build.log
> 
> + /usr/lib/rpm/find-debuginfo.sh --strict-build-id -p
''/.*/2.6.24-14.fc9(-ppc)?/.*|/.*2.6.24-14.fc9'' -o
debuginfo.list -p
''/.*/2.6.24-14.fc9-?smp(-ppc)?/.*|/.*2.6.24-14.fc9smp'' -o
debuginfosmp.list -p
''/.*/2.6.24-14.fc9-?PAE(-ppc)?/.*|/.*2.6.24-14.fc9PAE'' -o
debuginfoPAE.list -p
''/.*/2.6.24-14.fc9-?PAEdebug(-ppc)?/.*|/.*2.6.24-14.fc9PAEdebug''
-o debuginfoPAEdebug.list -p
''/.*/2.6.24-14.fc9-?debug(-ppc)?/.*|/.*2.6.24-14.fc9debug'' -o
debuginfodebug.list -p
''/.*/2.6.24-14.fc9-?xen(-ppc)?/.*|/.*2.6.24-14.fc9xen'' -o
debuginfoxen.list -p
''/.*/2.6.24-14.fc9-?kdump(-ppc)?/.*|/.*2.6.24-14.fc9kdump'' -o
debuginfokdump.list /builddir/build/BUILD/kernel-2.6.24
> extracting debug info from
/var/tmp/kernel-2.6.24-14.fc9-root-ppc/boot/vmlinuz-2.6.24-14.fc9
> extracting debug info from
/var/tmp/kernel-2.6.24-14.fc9-root-ppc/boot/vmlinuz-2.6.24-14.fc9smp
> extracting debug info from
/var/tmp/kernel-2.6.24-14.fc9-root-ppc/usr/lib/debug/lib/modules/2.6.24-14.fc9/vmlinux
> *** ERROR: same build ID in nonidentical files!
>         /usr/lib/debug/lib/modules/2.6.24-14.fc9/vmlinux
>    and  /boot/vmlinuz-2.6.24-14.fc9
> error: Bad exit status from /var/tmp/rpm-tmp.98614 (%install)
> 
Before this, it said:

*** WARNING: identical binaries are copied, not linked:
        /usr/lib/debug/lib/modules/2.6.24-9.fc9/vmlinux
   and  /boot/vmlinuz-2.6.24-9.fc9

In find-debuginfo.sh the two files are compared with both
''cmp'' and ''eu-elfcmp'' -- something has
changed that causes
them to be considered different where they weren''t before.

> Could this be yet another problem caused by the switch to GCC 4.3?
Hard to see what it could have done to cp. ;-)

+ cp vmlinux /var/tmp/kernel-2.6.24-14.fc9-root-ppc/boot/vmlinuz-2.6.24-14.fc9
...
+ cp vmlinux
/var/tmp/kernel-2.6.24-14.fc9-root-ppc/usr/lib/debug/lib/modules/2.6.24-14.fc9
> Before this, it said:
> 
> *** WARNING: identical binaries are copied, not linked:
>         /usr/lib/debug/lib/modules/2.6.24-9.fc9/vmlinux
>    and  /boot/vmlinuz-2.6.24-9.fc9
> 
> In find-debuginfo.sh the two files are compared with both
> ''cmp'' and ''eu-elfcmp'' -- something has
changed that causes
> them to be considered different where they weren''t before.
Off hand I would think this can only be eu-strip''s fault.
Unless something is silently touching files in the build
or something, then it looks like eu-strip run twice
(nondestructively) on the same input file produced
differing stripped files.

Rawhide has elfutils-0.132, which is also in updates-testing
for F-[78].  If it''s handy, you could try a kernel build on a
rawhide with elfutils downgraded and see if that fixes it, or
try a build on F-8 and see if it''s broken by upgrading to the
new elfutils from updates-testing.

I still haven''t fired up the ol'' G5 to look into the thing
with the vmlinux copies going into the wrong debuginfo rpms.
So when I get it together, I can look into this too.
I have to do a new rawhide install and such first though.


Thanks,
Roland

Oh wait, the "copied not linked" warning probaby explains the whole
thing.
The /usr/lib/debug copy is not stripped, so it''s not identical.
Yeah, ok.  I wonder why this wasn''t happening before.

I think it is just fixed by resolving the problems with too many copies of
vmlinux.


Thanks,
Roland

On 02/01/2008 04:22 PM, Roland McGrath wrote:
> Oh wait, the "copied not linked" warning probaby explains the
whole thing.
> The /usr/lib/debug copy is not stripped, so it''s not identical.
> Yeah, ok.  I wonder why this wasn''t happening before.
> 
Maybe the compiler is adding some new section type that eu-elfcmp
doesn''t
know it should be ignoring? (If either cmp or eu-elfcmp say the files are
identical the script treats them as such. And stripped and unstripped files
are found to be identical by eu-elfcmp on my F8 install...)

On Fri, 2008-02-01 at 13:22 -0800, Roland McGrath wrote:
> Oh wait, the "copied not linked" warning probaby explains the
whole thing.
> The /usr/lib/debug copy is not stripped, so it''s not identical.
But isn''t eu-elfcmp supposed to report that it matches? If I take a
copy
of a vmlinux file I happen to have lying around, then run eu-strip on it
and eu-elfcmp to compare the two, that doesn''t report that they differ
-- and it _shouldn''t_, should it?
> Yeah, ok.  I wonder why this wasn''t happening before.
> I think it is just fixed by resolving the problems with too many copies of
> vmlinux.
Which problems are those? It would be good to get this resolved ASAP so
that we can start building the kernel again...

-- 
dwmw2

On Fri, 01 Feb 2008 16:31:50 -0500
Chuck Ebbert <cebbert@redhat.com> wrote:
> On 02/01/2008 04:22 PM, Roland McGrath wrote:
> > Oh wait, the "copied not linked" warning probaby explains
the whole thing.
> > The /usr/lib/debug copy is not stripped, so it''s not
identical.
> > Yeah, ok.  I wonder why this wasn''t happening before.
> > 
> 
> Maybe the compiler is adding some new section type that eu-elfcmp
doesn''t
> know it should be ignoring? (If either cmp or eu-elfcmp say the files are
> identical the script treats them as such. And stripped and unstripped files
> are found to be identical by eu-elfcmp on my F8 install...)
I''m not entirely sure what this means, but here''s what I did:

1) mock build of a ppc kernel
2) Got this for failure:

extracting debug info from
/var/tmp/kernel-2.6.24.1-26.fc9-root-ppc/boot/vmlinuz-2.6.24.1-26.fc9
*** ERROR: same build ID in nonidentical files!
        /boot/vmlinuz-2.6.24.1-26.fc9
   and  /usr/lib/debug/lib/modules/2.6.24.1-26.fc9/vmlinux

3) went into the build root and did:
eu-elfcmp boot/vmlinuz-2.6.24.1-26.fc9 \
usr/lib/debug/lib/modules/2.6.24.1-26.fc9/vmlinux

and got:

differ: section header

4) ran:

eu-strip --remove-comment \
usr/lib/debug/lib/modules/2.6.24.1-26.fc9/vmlinux

5) did a eu-readelf -S of both files and noticed that the only
difference now was an additional .gnu_debuglink section in the
boot/vmlinuz file

6) ran the eu-elfcmp again on the two files and got no
error.

So I have no idea why eu-elfcmp doesn''t like something.  I did notice
that the unstripped vmlinux file has an additional .comment section in
it, so perhaps that''s throwing things off?  

If I run eu-strip without the --remove-comment argument on the
unstripped vmlinux file and then run eu-elfcmp, it does come back with
the differ: section header error.

The .comment section is filled with:

String section [30] ''.comment'' contains 39433 bytes at offset
0x47c000:
  [     0]  
  [     1]  GCC: (GNU) 4.3.0 20080130 (Red Hat 4.3.0-0.7)
  [    2f]  
  [    30]  GCC: (GNU) 4.3.0 20080130 (Red Hat 4.3.0-0.7)
  [    5e]  
  [    5f]  GCC: (GNU) 4.3.0 20080130 (Red Hat 4.3.0-0.7)
  ...

according to eu-readelf --strings=30 vmlinux

And now I''ll stop my random incoherent ramblings because ELF is hard
and makes my head hurt and I need to go play Wii or something.

josh

On Sat, 9 Feb 2008 20:14:39 -0600
Josh Boyer <jwboyer@gmail.com> wrote:
> > Maybe the compiler is adding some new section type that eu-elfcmp
doesn''t
> > know it should be ignoring? (If either cmp or eu-elfcmp say the files
are
> > identical the script treats them as such. And stripped and unstripped
files
> > are found to be identical by eu-elfcmp on my F8 install...)
> 
> I''m not entirely sure what this means, but here''s what I
did:
> 
> 1) mock build of a ppc kernel
> 2) Got this for failure:
> 
> extracting debug info from
/var/tmp/kernel-2.6.24.1-26.fc9-root-ppc/boot/vmlinuz-2.6.24.1-26.fc9
> *** ERROR: same build ID in nonidentical files!
>         /boot/vmlinuz-2.6.24.1-26.fc9
>    and  /usr/lib/debug/lib/modules/2.6.24.1-26.fc9/vmlinux
> 
> 3) went into the build root and did:
> eu-elfcmp boot/vmlinuz-2.6.24.1-26.fc9 \
> usr/lib/debug/lib/modules/2.6.24.1-26.fc9/vmlinux
> 
> and got:
> 
> differ: section header
> 
> 4) ran:
> 
> eu-strip --remove-comment \
> usr/lib/debug/lib/modules/2.6.24.1-26.fc9/vmlinux
> 
> 5) did a eu-readelf -S of both files and noticed that the only
> difference now was an additional .gnu_debuglink section in the
> boot/vmlinuz file
> 
> 6) ran the eu-elfcmp again on the two files and got no
> error.
> 
> So I have no idea why eu-elfcmp doesn''t like something.  I did
notice
> that the unstripped vmlinux file has an additional .comment section in
> it, so perhaps that''s throwing things off?  
> 
> If I run eu-strip without the --remove-comment argument on the
> unstripped vmlinux file and then run eu-elfcmp, it does come back with
> the differ: section header error.
> 
> The .comment section is filled with:
> 
> String section [30] ''.comment'' contains 39433 bytes at
offset 0x47c000:
>   [     0]  
>   [     1]  GCC: (GNU) 4.3.0 20080130 (Red Hat 4.3.0-0.7)
>   [    2f]  
>   [    30]  GCC: (GNU) 4.3.0 20080130 (Red Hat 4.3.0-0.7)
>   [    5e]  
>   [    5f]  GCC: (GNU) 4.3.0 20080130 (Red Hat 4.3.0-0.7)
>   ...
> 
> according to eu-readelf --strings=30 vmlinux
> 
> And now I''ll stop my random incoherent ramblings because ELF is
hard
> and makes my head hurt and I need to go play Wii or something.
I tried to build elfutils (on ppc) with an additional patch to spit out
exactly which section names it''s puking on in eu-elfcmp, but it fails
to finish building under gcc 4.3.  Seems ''make check'' fails
with:

section [36] ''.gnu.attributes'' has unsupported type 1879048181
*** failure in ../src/addr2line
section [38] ''.gnu.attributes'' has unsupported type 1879048181
*** failure in ../src/elfcmp
section [38] ''.gnu.attributes'' has unsupported type 1879048181
*** failure in ../src/elflint
section [37] ''.gnu.attributes'' has unsupported type 1879048181
*** failure in ../src/findtextrel
section [39] ''.gnu.attributes'' has unsupported type 1879048181
*** failure in ../src/ld
section [38] ''.gnu.attributes'' has unsupported type 1879048181
*** failure in ../src/nm
section [38] ''.gnu.attributes'' has unsupported type 1879048181
*** failure in ../src/objdump
section [38] ''.gnu.attributes'' has unsupported type 1879048181
*** failure in ../src/readelf
section [37] ''.gnu.attributes'' has unsupported type 1879048181
*** failure in ../src/size
section [38] ''.gnu.attributes'' has unsupported type 1879048181
*** failure in ../src/strip
section [37] ''.gnu.attributes'' has unsupported type 1879048181
*** failure in ../libelf/libelf.so
section [35] ''.gnu.attributes'' has unsupported type 1879048181
*** failure in ../libdw/libdw.so
section [36] ''.gnu.attributes'' has unsupported type 1879048181
*** failure in ../libasm/libasm.so
FAIL: run-elflint-self.sh

So elfutils isn''t happy with gcc adding .gnu.attributes sections or
something.

I noticed elfutils is on Jesse''s gcc 4.3 rebuild list.  Maybe once this
is fixed things will magically work again.  Of course, if Roland fixes
things, that is also indistinguishable from magic.

josh

David is correct that eu-elfcmp is meant to see the stripped and unstripped
files as matching.  Josh is correct that the .gnu.attributes section is the
new thing that is provoking the problem, owing to GCC 4.3.

I''m doing three things:

1. elfcmp''s bug is that it sees the .gnu.attribute sections in the
stripped
   and unstripped files as nonidentical.  This is a new section generated
   by GCC 4.3, which is not allocated but also is not stripped.  So in the
   stripped file, its sh_offset (file position) moves when the other
   nonallocated sections are removed.  I''ll fix it upstream to ignore
   sh_offset in the cases where doesn''t matter.  This won''t
hit rawhide
   especially soon.  (I''ll also deal with the elfutils vs 4.3 on ppc
issues
   Josh saw, but that is not anything to do with the kernel build.)

   This is moot wrt breaking the kernel build because of #3.

2. Part of the debuginfo_args magic macro''s regexp was wrong, so it
failed
   to match the /boot files.  This is why /usr/lib/debug/boot/*.debug all
   wound up in kernel-debuginfo-common.  I fixed the regexp so the .debug
   files for any unstripped ELF files in /boot will be sorted into the
   right kernel-debuginfo subpackage as originally intended.

   This is moot wrt reducing the total debuginfo rpm bloat because of #3.

3. We already copy the unstripped vmlinux into /usr/lib/debug.  
   (This is whence arises the comparison that hit bug #1.)
   So .debug files stripped from an ELF vmlinux installed into /boot
   just duplicates the bulky part of that, and bloats that debuginfo rpm.
   (With bug #2 fixed, this bloat is properly sorted into each kernel-debuginfo
   and kernel-foo-debuginfo rather than going into kernel-debuginfo-common.) 

   People prefer just having the unstripped vmlinux installed by
   kernel-debuginfo even when a split ELF /boot/vmlinux and .debug are
   available.  It''s simpler, and has the whole thing just by installing
   a kernel-debuginfo rpm without installing that kernel rpm in /boot.

   So, to dump the bloat we keep only one, and the unstripped vmlinux wins.
   The way to dump the /usr/lib/debug/boot/*.debug files is to strip the
   vmlinux we copy into /boot.  I''ve changed BuildKernel to do this.

   There are no other files that ever should have matched the part of the
   regexp that was wrong in bug #2, so that fix is masked by this change.
   Since the /boot files will be seen as stripped, they won''t be
processed
   by find-debuginfo.sh at all.  This circumvents bug #1.


Thanks,
Roland