8:53 a.m.
Building the free pascal compiler (package fpc) fails due to a
build-id/ld problem.
The compiler builds itself, using an older version of the compiler. Then
the compiler which is just build is used to build the same compiler
again. This iterative process continues until the generated binary and
the compiler-binary are the same. (It's called cylcling a compiler, most
compilers who can compile themselves use this technique)
But on F11/rawhide the two binaries never become the same, because they
all get a different build-id. On F10 this problen never occured, though.
According to the ld-manpage the build-id is the same when all the
object-files are exactly the same. But I think that isn't the case. I
tried --build-id=md5 and --build-id=sha1, both fail.
Any ideas how to fix this? Adding --build-id=none is a solution, but
then the rpm contains a binary without build-id.
Any other ideas? Is this maybe a ld-bug, or is it intentional?
Joost.
3:41 p.m.
We should figure out why they are different. (Off hand I don't think this
issue should have changed in the build tools since F10.)
Can you give me two binaries they you think ought to be identical, but
which had different build IDs generated?
I want to get to the bottom of the problem before you change anything.
But I'll note that if you were to use --build-id=none then you'd have your
rpm build break in the find-debuginfo.sh stage because of missing a build ID.
However, --build-id=0x00000000000000000000 (or any 20 hex digits you choose)
will hard-code that bogus build-ID during your link stages. That will make
your comparisons fine if your binaries are really identical. Then, the
find-debuginfo.sh stage will regenerate the build IDs after it edits the
source file names in the DWARF information.
But let's find the real source of the problem and fix it rather than
working around it.
Thanks,
Roland
8:13 a.m.
Sorry for the late response, I've missed your mail.
Op zondag 26-04-2009 om 13:41 uur [tijdzone -0700], schreef Roland
McGrath:
We should figure out why they are different. (Off hand I don't
think this
issue should have changed in the build tools since F10.)
Can you give me two binaries they you think ought to be identical, but
which had different build IDs generated?
Offcourse. I've placed a .tgz file here:
http://menora.cnoc.nl/extern/DifferentBuildIDsExample.tgz
It contains the source of a hello-world application. (hello.pp) And two
binaries (hello and hello1) which differ but were build from the same
source.
There's also a link-script (link.res) and a shell-script (ppas.sh) which
you can use to link the executables yourself. The necessary object files
are also there.
I want to get to the bottom of the problem before you change
anything.
But I'll note that if you were to use --build-id=none then you'd have your
rpm build break in the find-debuginfo.sh stage because of missing a build ID.
I know.
However, --build-id=0x00000000000000000000 (or any 20 hex digits you
choose)
will hard-code that bogus build-ID during your link stages. That will make
your comparisons fine if your binaries are really identical. Then, the
find-debuginfo.sh stage will regenerate the build IDs after it edits the
source file names in the DWARF information.
That's a nice trick. I could use that as a last resort.
But let's find the real source of the problem and fix it rather
than
working around it.
Thanks for the help,
Joost.
1:31 p.m.
Offcourse. I've placed a .tgz file here:
http://menora.cnoc.nl/extern/DifferentBuildIDsExample.tgz
It contains the source of a hello-world application. (hello.pp) And two
binaries (hello and hello1) which differ but were build from the same
source.
There's also a link-script (link.res) and a shell-script (ppas.sh) which
you can use to link the executables yourself. The necessary object files
are also there.
The 'hello' and 'hello1' binaries there are stripped.
Your 'link.res' script passes -s to ld, which explains why they are stripped.
But this defeats many purposes and hides the information I need to diagnose
your problem. Surely your actual package builds don't link with -s, I hope.
(If they do, your debuginfo rpms wind up useless.)
Thanks,
Roland
1:59 p.m.
Op dinsdag 19-05-2009 om 11:31 uur [tijdzone -0700], schreef Roland
McGrath:
> Offcourse. I've placed a .tgz file here:
> http://menora.cnoc.nl/extern/DifferentBuildIDsExample.tgz
>
> It contains the source of a hello-world application. (hello.pp) And two
> binaries (hello and hello1) which differ but were build from the same
> source.
>
> There's also a link-script (link.res) and a shell-script (ppas.sh) which
> you can use to link the executables yourself. The necessary object files
> are also there.
The 'hello' and 'hello1' binaries there are stripped.
Your 'link.res' script passes -s to ld, which explains why they are stripped.
But this defeats many purposes and hides the information I need to diagnose
your problem. Surely your actual package builds don't link with -s, I hope.
(If they do, your debuginfo rpms wind up useless.)
I've placed a new file with the same name with unstripped-binaries. I
just tried to make a simple example, but didn't realize that the
compiled would add '-s' to the link-script when no debug-information is
specified. (The script is generated by the compiler)
Can you have another look?
Joost.
3:34 p.m.
I've placed a new file with the same name with
unstripped-binaries. I
just tried to make a simple example, but didn't realize that the
compiled would add '-s' to the link-script when no debug-information is
specified. (The script is generated by the compiler)
Btw, note that "--build-id=md5" is not what you want to be using.
What gcc passes is just "--build-id", which defaults to
"--build-id=sha1".
fpc should use plain "--build-id" too.
The fact that the input files don't contain any debug info rules out the
kinds of problems I was expecting it would be. This just looks like a new
ld bug (a regression since F10).
https://bugzilla.redhat.com/show_bug.cgi?id=501582
Thanks,
Roland
3:57 p.m.
Op dinsdag 19-05-2009 om 13:34 uur [tijdzone -0700], schreef Roland
McGrath:
> I've placed a new file with the same name with
unstripped-binaries. I
> just tried to make a simple example, but didn't realize that the
> compiled would add '-s' to the link-script when no debug-information is
> specified. (The script is generated by the compiler)
Btw, note that "--build-id=md5" is not what you want to be using.
What gcc passes is just "--build-id", which defaults to
"--build-id=sha1".
fpc should use plain "--build-id" too.
It does. I was just testing different types.
The fact that the input files don't contain any debug info rules
out the
kinds of problems I was expecting it would be. This just looks like a new
ld bug (a regression since F10).
https://bugzilla.redhat.com/show_bug.cgi?id=501582
Thanks for the help. I hope that someone can fix this.
Joost
5453
days inactive
5477
days old
7 comments
3 participants
participants (3)
-
Joost van der Sluis -
Kevin Kofler -
Roland McGrath