Summary: | www-plugins/gnash-0.8.10_p20120903 - In file included from sound_definition.cpp:11: /usr/include/boost-1_49/boost/fusion/container/vector/detail/deref_impl.hpp:29:44: error: declaration does not declare anything | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | dehua.yang |
Component: | Current packages | Assignee: | Chí-Thanh Christopher Nguyễn <chithanh> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | PPC64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 445606 | ||
Bug Blocks: | |||
Attachments: |
build.log
Workaround patch to be applied to dev-libs/boost to avoid the gcc bug. Not a real fix. |
Description
dehua.yang
2012-11-05 08:28:25 UTC
I confirm this issue. It also happens on a 32-bit userland. The problems seems to be triggered by having -maltivec in CXXFLAGS. Line 29 of deref_impl.hpp looks like this: typedef typename Iterator::vector vector; But when -maltivec is specified, it comes out of the preprocessor like this (verified with gcc -E): typedef typename Iterator::vector; I don't know if this is a gcc bug or if the problem is with the headers, but I can get gcc to segfault by running "gcc -maltivec -E" on a file which contains just "vector vector", so it does smell a bit fishy in the gcc department... (My gcc version is "Gentoo 4.5.4 p1.0 pie-0.4.7" by the way.) Anyway, as a workaround to compile gnash, just remove -maltivec from CXXFLAGS. This needs to be done only for the directories libcore, libcore/parser, libcore/vm, gui, utilities, and extensions/dbus, which is where the boost vector class is used. -mabi=altivec should not be removed if present. No changes to CFLAGS are needed. (In reply to comment #1) > > Anyway, as a workaround to compile gnash, just remove -maltivec from > CXXFLAGS. This needs to be done only for the directories libcore, > libcore/parser, libcore/vm, gui, utilities, and extensions/dbus, which is > where the boost vector class is used. -mabi=altivec should not be removed if > present. No changes to CFLAGS are needed. It seems the workaround doesn't work in my system. I tried to compile libcore/vw manually by removing -maltivec from CXXFLAGS in Makefile, but it still had the same problems. Created attachment 331198 [details, diff]
Workaround patch to be applied to dev-libs/boost to avoid the gcc bug. Not a real fix.
Well, as an alternative workaround, you could try to apply the patch I just attached to dev-lib/boost (unfortunately, that ebuild does not seem to support /etc/portage/patches, so it takes some fiddling). That also fixes the problem for me. Anyway, since the core issue seems to be a gcc bug, I have opened a separate bug (#445606) about that, and made it a blocker for this one. So if I understand correctly, this is a bug in boost and not gnash (or gcc)? It is a gcc bug. I found out that it has been fixed upstreams in the gcc 4.7 series (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48226). And as I wrote in the other bug, putting the patch from the gcc bugzilla into /etc/portage/patches/sys-devel/gcc-4.5.4/ and re-emerging gcc fixes the problem. (In reply to comment #7) > And as I wrote in the other bug, putting the patch from the gcc bugzilla > into /etc/portage/patches/sys-devel/gcc-4.5.4/ and re-emerging gcc fixes the > problem. Thank you. I followed your instructions and ememrged the gnash successfully. Maybe we could close this bug if the gcc-power7 patch is applied to gcc-4.5.4. Issue #445606 has now been resolved, so this issue can probably be closed as well. In order to avoid duplicate reports, I will wait until next revision bump or stabilization (bug 418383) before closing. gcc-4.6 is stable now |