dev-util/oprofile fails to build with gcc 4.3 then mv -f ".deps/string_filter.Tpo" ".deps/string_filter.Po"; else rm -f ".deps/string_filter.Tpo"; exit 1; fi In file included from bfd_support.cpp:13: op_bfd.h:174: warning: type qualifiers ignored on function return type bfd_support.cpp: In function 'bool<unnamed>::get_debug_link_info(bfd*, std::string&, long unsigned int&)': bfd_support.cpp:81: error: 'exit' was not declared in this scope bfd_support.cpp:85: error: 'strlen' was not declared in this scope bfd_support.cpp: In function 'bool interesting_symbol(asymbol*)': bfd_support.cpp:338: error: 'strcmp' was not declared in this scope bfd_support.cpp:352: error: 'strcmp' was not declared in this scope bfd_support.cpp: In destructor 'bfd_info::~bfd_info()': bfd_support.cpp:406: error: 'free' was not declared in this scope In file included from op_bfd.cpp:26: op_bfd.h:174: warning: type qualifiers ignored on function return type make[3]: *** [bfd_support.o] Error 1 make[3]: *** Waiting for unfinished jobs.... op_bfd.cpp:169: warning: type qualifiers ignored on function return type make[3]: Leaving directory `/var/tmp/paludis/dev-util-oprofile-0.9.3/work/oprofile-0.9.3/libutil++' make[2]: *** [all-recursive] Error 1 Reproducible: Always Steps to Reproduce:
Created attachment 150492 [details, diff] gcc-4.3 patch Patch from http://article.gmane.org/gmane.linux.oprofile/5477
Fixed in CVS. Thanks for the patch!
Created attachment 151722 [details] Output of failure to apply patch The patch which "fixes" this bug doesn't apply cleanly for me, breaking what was previously a stable ebuild when attempting to re-emerge.
Also, rather than altering existing stable packages, shouldn't an -r1 be created for something like this, so people can at least re-emerge the old version if they have problems? Prior to the inclusion of this patch I had oprofile 0.9.3 installed perfectly well; now, it's preventing me from finishing an "emerge -e world", so it's not something I can easily skip over and I don't particularly fancy restarting from scratch.
Philip: The patch applies here. With some fuzz. Are you sure it's not something wrong on your end? Given the 'patch: **** malformed patch at line 4:' could you perhaps try to resync.
That's the first thing I tried, and it didn't help. In the end I got around it and finished my emerge by simply disabling the patch and re-digesting the ebuild (I'm not using GCC 4.3); not a pretty solution. My system's rebuild has finished now, so at least I'm free to have a proper play around with this, anyway. Having tried again just now I get the exact same error, so either I'm syncing with a bad source, or the patch really, really doesn't apply... any other info I could give you? Other things I could try?
Created attachment 151829 [details, diff] Revised patch Could you please try the attached patch. It's a revised patch that applies completely clean for me. If this doesn't help we are going to have to wait for smarter people to pitch in. I'm out of ideas.
I also came across the exact same issues that Philip did. In a nutshell: ====================================== PATCH COMMAND: patch -p1 -g0 -E --no-backup-if-mismatch < /usr/portage/dev-util/oprofile/files/oprofile-0.9.3-gcc43.patch ====================================== patching file pp/oparchive.cpp patch: **** malformed patch at line 4: The proposed patch does indeed work however: root@ns1:/var/tmp/portage/dev-util/oprofile-0.9.3/work/oprofile-0.9.3 # patch -p1 < /tmp/op.patch patching file gui/oprof_start_util.cpp patching file libabi/opimport.cpp patching file libpp/op_header.cpp patching file libpp/profile.cpp patching file libpp/sample_container.cpp patching file libregex/demangle_symbol.cpp patching file libutil++/bfd_spu_support.cpp patching file libutil++/bfd_support.cpp patching file libutil++/child_reader.cpp patching file libutil++/cverb.cpp patching file libutil++/file_manip.cpp patching file libutil++/op_spu_bfd.cpp patching file pp/common_option.cpp patching file pp/opannotate_options.cpp patching file pp/oparchive.cpp patching file pp/opgprof_options.cpp However, this patch actually needs to be commited to the portage tree to be useful. BTW, Philip, you know that for any package that appears to be preventing an emerge succeeding, you can always do "emerge --resume --skip-first" and it will skip over said build leaving the original intact. In most cases it's perfectly acceptable to leave an older build around until an issue is resolved - atleast if you want to see your emerge actually finish. It's especially a common issue these days with gcc 4.3.0's header streamlining changes and various C++ builds.
Ah! No, I didn't know that; thanks for the tip. :) Unfortunately I won't be able to try out the revised patch for myself for the next week; the problem is on my office box, not my home box (not using oprofile outside work currently), and I'm away for a week so won't be near either of them anyway. I will make a note to try it when I get back, but it sounds from Christopher's comments like it does the trick.
Reopening. Michal: Could you please push the revised patch. I don't know why the previous patch applies for some while it fails for others. But I guess the new one is better anyways.
Peter: thanks for the updated patch. I have put it in CVS. Hopefully this will fix the problem Philip and Christopher have encountered.
Created attachment 154063 [details, diff] additional patch to fix make check Hi, here is a patch that fixes compilation failure during make check (previous patches only covered compile phase)