Compiling mesa on hardened ~x86, configure bailed out stating that gcc could not produce executables. It turned out that any attempt to compile a program using the -ffast-math option leads to an undefined symbol error: gcc -ffast-math test.c -o test /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/crtfastmath.o:(.ctors+0x0): undefined reference to `no symbol' collect2: ld gab 1 als Ende-Status zurück $ gcc -ffast-math test.c -o test.o -c $ readelf -s test.o Symbol table '.symtab' contains 14 entries: Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND 1: 00000000 0 FILE LOCAL DEFAULT ABS test.c 2: 00000000 0 SECTION LOCAL DEFAULT 2 3: 00000000 0 SECTION LOCAL DEFAULT 4 4: 00000000 0 SECTION LOCAL DEFAULT 5 5: 00000000 0 SECTION LOCAL DEFAULT 6 6: 00000000 0 SECTION LOCAL DEFAULT 8 7: 00000000 0 SECTION LOCAL DEFAULT 9 8: 00000000 0 SECTION LOCAL DEFAULT 7 9: 00000000 0 SECTION LOCAL DEFAULT 1 10: 00000000 58 FUNC GLOBAL DEFAULT 2 main 11: 00000000 0 FUNC GLOBAL HIDDEN 8 __i686.get_pc_thunk.bx 12: 00000000 0 NOTYPE GLOBAL DEFAULT UND _GLOBAL_OFFSET_TABLE_ 13: 00000000 0 NOTYPE GLOBAL DEFAULT UND puts There shouldn't be any FP-operation in test.c: include <stdio.h> int main() { printf("hello world\n"); return 0; } Linking -lm explictly doesn't help. The generated assembly and object files are identical, with and without-ffast-math, while only the link without -ffast-math succeeds. I use sys-devel/binutils-2.19-r1.
*** Bug 288988 has been marked as a duplicate of this bug. ***
*** Bug 288986 has been marked as a duplicate of this bug. ***
*** Bug 288985 has been marked as a duplicate of this bug. ***
*** Bug 288984 has been marked as a duplicate of this bug. ***
*** Bug 288982 has been marked as a duplicate of this bug. ***
*** Bug 288980 has been marked as a duplicate of this bug. ***
*** Bug 288979 has been marked as a duplicate of this bug. ***
Deleted seven copies of this bug, which were created due to a persistent bugzilla error (stating something like it was insecure to run a certain perl script with the -t switch -- didn't copy).
add emerge --info to any bug report you report please.
I'm unable to reproduce on hardened/x86 with binutils-2.18-r3. symtab looks same though. Possibly dependant on binutils-2.19-r1 to reproduce or inspect crtfastmath.o?
(In reply to comment #9) > add emerge --info to any bug report you report please. > I tried to attach this information several times, but constantly encountered bugzilla errors. See https://bugs.gentoo.org/show_bug.cgi?id=289051 for details.
(In reply to comment #10) > I'm unable to reproduce on hardened/x86 with binutils-2.18-r3. symtab looks > same though. Possibly dependant on binutils-2.19-r1 to reproduce or inspect > crtfastmath.o? > There seem to be a hidden bug in ld since years: http://forums.gentoo.org/viewtopic-t-293224-start-0.html http://www.nabble.com/Linker-errors-I-don't-understand-td25881112.html -- and more like these even here in gentoo bugzilla, but closed due to lacking information. That ld is currently unable to diagnose the problem exactly may also be a consequence of gcc generating undefined symbols with no type: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35514 Otherwise, there aren't any open bugs in gcc or binutils bugzilla regarding "undefined reference to `no symbol'" or "-ffast-math".
Try building gcc without FEATURES="installsources" The problem occurs during the ebuild install phase when copying crtfastmath.o (and crtprec[32|64|80].o) from the 'work' tree to the 'image' tree.
Created attachment 207116 [details] emerge --info output Attempting again to add emerge --info, this time with session cookies globally enabled ...
(In reply to comment #13) > Try building gcc without FEATURES="installsources" > > The problem occurs during the ebuild install phase when copying crtfastmath.o > (and crtprec[32|64|80].o) from the 'work' tree to the 'image' tree. > Compiling ... But could you elaborate on this? Sure, I had installsources in FEATURES, and, checking the previous emerge log for gcc, actually rscync said it encountered problems transferring source files associated with crtfastmath.o. But, as I read the ebuild log, this should not concern the binary itself? I checked /usr/lib/gcc/: -rw-r--r-- 1 root root 968 6. Okt 19:28 i686-pc-linux-gnu/4.3.4/crtfastmath.o -rw-r--r-- 1 root root 784 6. Okt 19:28 i686-pc-linux-gnu/4.3.4/crtprec32.o -rw-r--r-- 1 root root 792 6. Okt 19:28 i686-pc-linux-gnu/4.3.4/crtprec64.o -rw-r--r-- 1 root root 784 6. Okt 19:28 i686-pc-linux-gnu/4.3.4/crtprec80.o
Ok. Recompiling gcc without "installsources" in FEATURES solved the case. But I still doubt that it really had something to do with the "installsources" feature. Will now recompile gcc once more with installsources reenabled, in order to see if I encountered a transient problem only. Even though it was already the second time that gcc-4.3.4 recompiles itself, the files in question are a few bytes shorter now: -rw-r--r-- 1 root root 952 14. Okt 22:39 i686-pc-linux-gnu/4.3.4/crtfastmath.o -rw-r--r-- 1 root root 768 14. Okt 22:39 i686-pc-linux-gnu/4.3.4/crtprec32.o -rw-r--r-- 1 root root 776 14. Okt 22:39 i686-pc-linux-gnu/4.3.4/crtprec64.o -rw-r--r-- 1 root root 768 14. Okt 22:39 i686-pc-linux-gnu/4.3.4/crtprec80.o
Interestingly, Graham is right. When gcc was rebuild with installsources reenabled, the same off behaviour resurfaces. Also the size of the -ffast-math related object files increases again: -rw-r--r-- 1 root root 968 15. Okt 01:03 i686-pc-linux-gnu/4.3.4/crtfastmath.o -rw-r--r-- 1 root root 784 15. Okt 01:03 i686-pc-linux-gnu/4.3.4/crtprec32.o -rw-r--r-- 1 root root 792 15. Okt 01:03 i686-pc-linux-gnu/4.3.4/crtprec64.o -rw-r--r-- 1 root root 784 15. Okt 01:03 i686-pc-linux-gnu/4.3.4/crtprec80.o Looking for the difference? With "installsources" enabled, gcc (or whatever) inserts an undefined and untyped global symbol into all these files, for example: $ readelf -s /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/crtfastmath.o Symbol table '.symtab' contains 8 entries: Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND 1: 00000000 0 SECTION LOCAL DEFAULT 1 2: 00000000 0 SECTION LOCAL DEFAULT 2 3: 00000000 0 SECTION LOCAL DEFAULT 3 4: 00000000 0 SECTION LOCAL DEFAULT 4 5: 00000000 0 SECTION LOCAL DEFAULT 6 6: 00000000 0 SECTION LOCAL DEFAULT 7 7: 00000000 0 NOTYPE GLOBAL DEFAULT UND Which just isn't present if gcc was emerged without the "installsources" feature: $readelf -s 4.3.4-no-installsources/crtfastmath.o Symbol table '.symtab' contains 7 entries: Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND 1: 00000000 0 SECTION LOCAL DEFAULT 1 2: 00000000 0 SECTION LOCAL DEFAULT 2 3: 00000000 0 SECTION LOCAL DEFAULT 3 4: 00000000 0 SECTION LOCAL DEFAULT 4 5: 00000000 0 SECTION LOCAL DEFAULT 6 6: 00000000 0 SECTION LOCAL DEFAULT 7 $objdump -t /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/crtfastmath.o /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/crtfastmath.o: file format elf32-i386 SYMBOL TABLE: 00000000 l d .text 00000000 .text 00000000 l d .data 00000000 .data 00000000 l d .bss 00000000 .bss 00000000 l d .ctors 00000000 .ctors 00000000 l d .comment 00000000 .comment 00000000 l d .note.GNU-stack 00000000 .note.GNU-stack 00000000 *UND* 00000000 Which would likely explain ld's undefined reference to "no symbol". $ objdump -t 4.3.4-no-installsources/crtfastmath.o 4.3.4-no-installsources/crtfastmath.o: file format elf32-i386 SYMBOL TABLE: 00000000 l d .text 00000000 .text 00000000 l d .data 00000000 .data 00000000 l d .bss 00000000 .bss 00000000 l d .ctors 00000000 .ctors 00000000 l d .comment 00000000 .comment 00000000 l d .note.GNU-stack 00000000 .note.GNU-stack I'm using dev-util/debugedit-4.4.6-r1. Does debugedit misbehave if "installsources" is enabled?
(In reply to comment #15) > (In reply to comment #13) > > Try building gcc without FEATURES="installsources" > > > > The problem occurs during the ebuild install phase when copying crtfastmath.o > > (and crtprec[32|64|80].o) from the 'work' tree to the 'image' tree. > > > > Compiling ... But could you elaborate on this? Here are the relocation sections from objdump -x crtfastmath.o from the work and image trees after running 'ebuild gcc-4.4.1.ebuild install' Build:RELOCATION RECORDS FOR [.debug_line]: OFFSET TYPE VALUE 0000008a R_386_32 .text RELOCATION RECORDS FOR [.ctors]: OFFSET TYPE VALUE 00000000 R_386_32 .text RELOCATION RECORDS FOR [.debug_aranges]: OFFSET TYPE VALUE 00000006 R_386_32 .debug_info 00000010 R_386_32 .text RELOCATION RECORDS FOR [.eh_frame]: OFFSET TYPE VALUE 00000020 R_386_PC32 .text Image:RELOCATION RECORDS FOR [.ctors]: OFFSET TYPE VALUE 00000000 R_386_32 RELOCATION RECORDS FOR [.eh_frame]: OFFSET TYPE VALUE 00000020 R_386_PC32
debugedit isnt widely used, but there arent known problems with it (so far) it doesnt misbehave based on "installsources". that feature only controls whether it's run. i'm guessing the issue isnt strictly tied to hardened ? people with a non-hardened toolchain should be able to reproduce right ?
(In reply to comment #19) > people with a non-hardened toolchain should be able to reproduce right ? afaict, yeah. that was my reasoning for reassigning to toolchain@ with hardened@ benchwarming on the CC.
i dont suppose you could find the exact debugedit command used on the .o to produce a bad result ? going by prepstrip, it should look something like: debugedit \ -b /var/tmp/portage/sys-devel/gcc-4.3.4/work \ -d /usr/src/debug/sys-devel/gcc-4.3.4 \ foo.o if that produces the same bad .o behavior, please post the good .o and the bad .o as attachments
I am not using the hardened toolchain. I have grepped /var/log/portage/sys-dev:gcc-4.4.1* from debugedit and it does not show, so sorry I cannot give the exact invocation. If it is of any help, this problem only manifests if INSTALLSOURCES is specified, it does NOT manifest with just SPLITDEBUG which also calls debugedit.
splitdebug is not terribly relevant. debugedit is used to *query* the objects in the splitdebug code. it has no part at all in the actual splitting of the debug code. objcopy takes care of all of that.
(In reply to comment #23) > splitdebug is not terribly relevant. debugedit is used to *query* the objects > in the splitdebug code. it has no part at all in the actual splitting of the > debug code. objcopy takes care of all of that. > Except that debugedit actually alters the objectfile. Since ebuild or emerge --debug does not help, "set -x" embedded in "/usr/lib/portage/bin/ebuild-helpers" gives the debugedit commandline: debugedit -b /mnt/hda1/tmp/portage/sys-devel/gcc-4.3.4/work -d /usr/src/debug/sys-devel/gcc-4.3.4 -l /mnt/hda1/tmp/portage/sys-devel/gcc-4.3.4/temp/debug.sources /mnt/hda1/tmp/portage/sys-devel/gcc-4.3.4/image//usr/lib/gcc/i686-pc-linux-gnu/4.3.4/crtfastmath.o Now, step-by step. ebuild gcc-4.3.4.ebuild install did already run. $ 4.3.4 # pwd /var/tmp/portage/sys-devel/gcc-4.3.4/image/usr/lib/gcc/i686-pc-linux-gnu/4.3.4 $ 4.3.4 # rm crtfastmath.o $ 4.3.4 # find /var/tmp/portage/sys-devel/gcc-4.3.4/work/build -name crtfastmath.o /var/tmp/portage/sys-devel/gcc-4.3.4/work/build/i686-pc-linux-gnu/libgcc/crtfastmath.o /var/tmp/portage/sys-devel/gcc-4.3.4/work/build/gcc/crtfastmath.o $ 4.3.4 # diff /var/tmp/portage/sys-devel/gcc-4.3.4/work/build/i686-pc-linux-gnu/libgcc/crtfastmath.o $ 4.3.4 # diff /var/tmp/portage/sys-devel/gcc-4.3.4/work/build/i686-pc-linux-gnu/libgcc/crtfastmath.o /var/tmp/portage/sys-devel/gcc-4.3.4/work/build/gcc/crtfastmath.o $ 4.3.4 # readelf -s /var/tmp/portage/sys-devel/gcc-4.3.4/work/build/gcc/crtfastmath.o Symbol table '.symtab' contains 17 entries: Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND 1: 00000000 0 FILE LOCAL DEFAULT ABS crtfastmath.c 2: 00000000 0 SECTION LOCAL DEFAULT 1 3: 00000000 0 SECTION LOCAL DEFAULT 2 4: 00000000 0 SECTION LOCAL DEFAULT 3 5: 00000000 0 SECTION LOCAL DEFAULT 4 6: 00000000 0 SECTION LOCAL DEFAULT 5 7: 00000000 0 SECTION LOCAL DEFAULT 7 8: 00000000 205 FUNC LOCAL DEFAULT 1 set_fast_math 9: 00000000 0 SECTION LOCAL DEFAULT 9 10: 00000000 0 SECTION LOCAL DEFAULT 11 11: 00000000 0 SECTION LOCAL DEFAULT 13 12: 00000000 0 SECTION LOCAL DEFAULT 14 13: 00000000 0 SECTION LOCAL DEFAULT 16 14: 00000000 0 SECTION LOCAL DEFAULT 17 15: 00000000 0 SECTION LOCAL DEFAULT 19 16: 00000000 0 SECTION LOCAL DEFAULT 18 $ 4.3.4 # pwd /var/tmp/portage/sys-devel/gcc-4.3.4/image/usr/lib/gcc/i686-pc-linux-gnu/4.3.4 $ 4.3.4 # cp /var/tmp/portage/sys-devel/gcc-4.3.4/work/build/i686-pc-linux-gnu/libgcc/crtfastmath.o . -a $ 4.3.4 # debugedit -b /mnt/hda1/tmp/portage/sys-devel/gcc-4.3.4/work -d /usr/src/debug/sys-devel/gcc-4.3.4 -l /mnt/hda1/tmp/portage/sys-devel/gcc-4.3.4/temp/debug.sources /mnt/hda1/tmp/portage/sys-devel/gcc-4.3.4/image//usr/lib/gcc/i686-pc-linux-gnu/4.3.4/crtfastmath.o $ 4.3.4 # readelf -s crtfastmath.o Symbol table '.symtab' contains 17 entries: Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND 1: 00000000 0 NOTYPE LOCAL DEFAULT UND 2: 00000000 0 NOTYPE LOCAL DEFAULT UND 3: 00000000 0 NOTYPE LOCAL DEFAULT UND 4: 00000000 0 NOTYPE LOCAL DEFAULT UND 5: 00000000 0 NOTYPE LOCAL DEFAULT UND 6: 00000000 0 NOTYPE LOCAL DEFAULT UND 7: 00000000 0 NOTYPE LOCAL DEFAULT UND 8: 00000000 0 NOTYPE LOCAL DEFAULT UND 9: 00000000 0 NOTYPE LOCAL DEFAULT UND 10: 00000000 0 NOTYPE LOCAL DEFAULT UND 11: 00000000 0 NOTYPE LOCAL DEFAULT UND 12: 00000000 0 NOTYPE LOCAL DEFAULT UND 13: 00000000 0 NOTYPE LOCAL DEFAULT UND 14: 00000000 0 NOTYPE LOCAL DEFAULT UND 15: 00000000 0 NOTYPE LOCAL DEFAULT UND 16: 00000000 0 NOTYPE LOCAL DEFAULT UND Will attach the original and the "debugedited" version of crtfastmath.o
Created attachment 207285 [details] Original crtfastmath.o from build/gcc
Created attachment 207287 [details] Version of crtfastmath.o produced by the debugedit run on /var/tmp/portage/sys-devel/gcc-4.3.4/image/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/crtfastmath.o
Would like to take the opportunity to hint to another, really minor problem in /usr/lib/portage/bin/ebuild-helpers/prepstrip. Within save_elf_sources(), line 56, which is "grep -zv '/<built-in>$' "${T}"/debug.sources \" does not take into account, that localized gcc outputs e.g. "<eingebaut>" instead of "<built-in>", which regularily leads to annoyant rsync warnings.
you're confusing things. that output is from *installsources*, not *splitdebug*. no one has complained about rsync warnings before (and i havent seen any), so no one has looked into it.
(In reply to comment #28) May be or may be not. But if one bothers to file a single Gentoo bug report, one could file three, plus at least one so-called social bug. Anyway, if someone had incorporated the patch proposed by Christopher Layne (in https://bugs.gentoo.org/show_bug.cgi?id=220086) almost a year ago, debugedit would now have a switch -r (for readonly). Then a one line patch could cure this problem once and for all: --- a/prepstrip 2009-10-16 20:03:50.000000000 +0200 +++ b/prepstrip 2009-10-16 20:04:13.000000000 +0200 @@ -49,7 +49,7 @@ local inode=$(inode_var_name "$x") [[ -n ${!inode} ]] && return 0 local sources_dir=/usr/src/debug/${CATEGORY}/${PF} - debugedit -b "${WORKDIR}" -d "${sources_dir}" \ + debugedit -r -b "${WORKDIR}" -d "${sources_dir}" \ -l "${T}"/debug.sources "${x}" if [[ -s ${T}/debug.sources ]] ; then [[ -d ${D}${sources_dir} ]] || mkdir -p "${D}${sources_dir}"
i really have no idea what you're talking about wrt bugs as for -r "fixing" the issue at hand, it wouldnt. the debugedit command isnt used just for saving sources, it is also used to adjust the path in the binary on purpose. making the operation read only would defeat that.
(In reply to comment #30) > as for -r "fixing" the issue at hand, it wouldnt. the debugedit command isnt > used just for saving sources, it is also used to adjust the path in the binary > on purpose. making the operation read only would defeat that. Regrettably, this seems to be true. gdb does not find source files any more, if preprstrip was altered to include the -r switch for debugedit. As for my comment that you could file at least three bugs while you are examining the first one: prepstrip seems to contains another bug. 72 local buildid="$( type -P debugedit >/dev/null && debugedit -i "${x}" )" There isn't a "-i" switch for debugedit. Since debugedit currently does not complain about invalid switches on it's commandline, "buildid" always evaluates to an empty string. I'm unsure if this was intended.
*** Bug 289837 has been marked as a duplicate of this bug. ***
Having tried *everything*, I found the culprit; downgrading elfutils from 0.143 to 0.140 solved it.
(In reply to comment #33) > Having tried *everything*, I found the culprit; downgrading elfutils from 0.143 > to 0.140 solved it. > ebuild elfutils-0.143.ebuild test says: =================== All 68 tests passed =================== Elfutils gitweb repository is here: http://git.fedorahosted.org/git/elfutils.git?p=elfutils.git;a=summary There are 127 commits between the 0.140 and 1.143 versions. Any idea for a git-bisect test case which doesn't involve something like "ebuild gcc-4.3.4.ebuild install"?
When constructing a repro-case, I hit this assertion with elfutils-0.140: debugedit: elf32_updatefile.c:380: __elf64_updatemmap: Assertion `scn_start + dl->data.d.d_off + dl->data.d.d_size == last_position' failed. Looking through my old build logs, I see that this has been present for a long time, but disappeared when elfutils-0.143 was installed. I've found the commit that fixes that assertion. I'm betting beer that it's the culprit. Upstream bug with the patch that fixed the assertion: https://bugzilla.redhat.com/show_bug.cgi?id=512840 Gitweb link: http://git.fedorahosted.org/git/elfutils.git?p=elfutils.git;a=commitdiff;h=fa1d4447b16f16ff9056a24163b175fcbc3a57cf I'm on my way to doing stuff, so if someone can check if reverting that brings back the assertion, it'd be nice.
Created attachment 207806 [details] testscript Will output something like: 8: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND To &1 when elfutils-0.143 is used. Nothing if elfutils-0.140. You need crtfastmath.c from gcc to run it.
(In reply to comment #35) > I'm on my way to doing stuff, so if someone can check if reverting that brings > back the assertion, it'd be nice. > $ git revert fa1d4447b16f16ff9056a24163b175fcbc3a57cf Automatic revert failed. After resolving the conflicts [...] Doing the revert by hand within elfutils-0.143 actually brings back that assertion: $ ./testscript debugedit: elf32_updatefile.c:380: __elf32_updatemmap: Assertion `scn_start + dl->data.d.d_off + dl->data.d.d_size == last_position' failed. ./testscript: Zeile 6: 31887 Abgebrochen debugedit -b $(pwd) -d chookafluie -l debug crtfastmath.o As a double check against stale files, I reapplied the patch and reinstalled, with the result that the assertion vanished again.
Using git bisect to nail down the problem in elflib is problematic, possibly because the assertion in line 380 within elf32_updatefile.c is itself inconsistent. Said assertion covers the error behind the scene and debugedit regularily aborts. I therefore commented out the assertion while bisecting, and finally got this result: fa1d4447b16f16ff9056a24163b175fcbc3a57cf is the first bad commit commit fa1d4447b16f16ff9056a24163b175fcbc3a57cf Author: Lubomir Rintel <lkundrak@v3.sk> Date: Tue Jul 21 21:04:47 2009 -0700 Fix handling of gaps between sections when writing files in libelf. So Alan's suspicion was right on the spot. Using his "testscript", I tested the same set of changes (revert commit and remove assertion) also within dev-libs/elfutils-0.143 tree: all ok. A last note: The package dev-libs/elfutils-0.143 also provides a program named "eu-elflint". elflint fails to recognize any problem with crtfastmath.o.
Created attachment 208000 [details] Proposed fix Thank you for reporting this problem. Could you please try the patching elfutils with the attached patch and let me know if it fixes things for you (and doesn't break something else)?
(In reply to comment #39) > Could you please try the patching elfutils with the attached patch and let me > know if it fixes things for you (and doesn't break something else)? Thank you very much for the quick reaction. I successfully tested your patch after rebasing it on dev-libs/elfutils-0.143. "debugedit" now works correctly. I'll attach the rebased patch against libelf/elf32_updatefile.c, for others being able to repeat the test within their environments. As for I've seen that you mentioned my name in your patch, please consider to add Graham Murray in the first place, as he instantly identified the constellation which directly pointed to a problem with debugedit, which Peter Hutterer in turn quickly diagnosed to be an intrinsic problem in libelf. I merely followed their respective hypothesis. I would like to point out some spin-off (or should I say: fallout) of this bug: 1.) debugedit -i switch does not exist any more,"prepstrip" is currently wrong 2.) debugedit does not check for unsupported commandline switches. 3.) the elfutils regression testsuite does not cover object file corruption 4.) eu-elflint does not recognize any problem with the mangled file 5.) the ebuild --debug switch did not help to trace the debugedit actions 6.) gcc,ld or perhaps debugedit do generate localized values: cf. <eingebaut> vs. <built-in>, which is pointless and does complicate postprocessing (comment #27)
Created attachment 208084 [details, diff] Lubomir Rintel's patch rebased on elfutils-0.143
(In reply to comment #40) > As for I've seen that you mentioned my name in your patch, please consider to > add Graham Murray in the first place, as he instantly identified the > constellation which directly pointed to a problem with debugedit, which Peter > Hutterer in turn quickly diagnosed to be an intrinsic problem in libelf. I > merely followed their respective hypothesis. Hutterer? > I would like to point out some spin-off (or should I say: fallout) of this bug: > 1.) debugedit -i switch does not exist any more,"prepstrip" is currently wrong Correction: Never did in Gentoo's version of debugedit. It would pull in beecrypt which would needlessly inflate dependencies. > 6.) gcc,ld or perhaps debugedit do generate localized values: cf. <eingebaut> > vs. <built-in>, which is pointless and does complicate postprocessing (comment > #27) Fixed, bug 289967
(In reply to comment #42) > (In reply to comment #40) > Hutterer? That's the second time I mistook your name. Peter Alfredsen, please excuse my negligence.
if you look at the history of prepstrip, the -i is intentional. it requires a newer debugedit but should be harmless when using older ones. wrt elfutils issues, you can try reporting those to the elfutils maintainers, but i doubt you'll get much response w/out patches, and probably not even then --debug recursing into shell scripts is now Bug 290341
Thanks for the feedback! A ticket was filed upstream here: https://bugzilla.redhat.com/show_bug.cgi?id=530704
(In reply to comment #45) Lubomir, Peter had already filed a very stringent redhat/fedora bug report, which even includes a reproducer here: https://bugzilla.redhat.com/show_bug.cgi?id=530532 I don't have a redhat bugzilla account (and don't plan to create one), so perhaps you could to add a reference to link both entries. (In reply to comment #44) >if you look at the history of prepstrip, the -i is intentional. it requires a >newer debugedit but should be harmless when using older ones. As Peter explained (in comment #42), Gentoo's version of debugedit never had the -i switch, so this is just dead code awaiting the hell to freeze over. >wrt elfutils issues, you can try reporting those to the elfutils maintainers, >but i doubt you'll get much response w/out patches, and probably not even then Understandable -- their code base appears to be unmaintainable. With each new FC version, they simply close all open bug reports, hoping for better weather. When I looked into libelf/elf32_updatefile.c, trying to understand that wired code which jumps across sparsely commented pages of long-winded stuff, with pointer arithmetics distributed over the whole file, I thought it would be more reliable if one could find a clean solution to replace libelf and debugedit in the context of Portage, much like the "objcopy --add-gnu-debuglink" switch. The elfutils project was started by RH to squeeze out GNU binutils, but became at least as ugly as the collection of programs centered around libbfd (and see the telling comments regarding elfutils on http://people.redhat.com/drepper/; you need to enable javascript to read them).
*** Bug 291337 has been marked as a duplicate of this bug. ***
*** Bug 291935 has been marked as a duplicate of this bug. ***
*** Bug 293798 has been marked as a duplicate of this bug. ***
thanks all ... fix is in 0.143-r1
Fixed upstream in elfutils-0.144
