Bugzilla Bug 218727

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 an attachment (id=150492) [details]
gcc-4.3 patch

Patch from http://article.gmane.org/gmane.linux.oprofile/5477

Fixed in CVS.  Thanks for the patch!

Created an attachment (id=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 an attachment (id=151829) [details]
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 an attachment (id=154063) [details]
additional patch to fix make check

Hi, here is a patch that fixes compilation failure during make check (previous
patches only covered compile phase)