| Summary: | x11-libs/libcompizconfig-0.8.8 and dev-libs/icu-57.1 - error: template with C linkage | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Martin von Gagern <Martin.vGagern> |
| Component: | Current packages | Assignee: | Desktop-Effects herd <desktop-effects+disabled> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | joost.ruis, pvdabeel |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://github.com/compiz-reloaded/libcompizconfig/commit/1e42ea0e629d6a013e6e7ad7f5d1bbfd2ea11338 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | patch from compiz-reloaded GitHub | ||
Created attachment 458998 [details, diff]
patch from compiz-reloaded GitHub
*** This bug has been marked as a duplicate of bug 602286 *** |
Building libcompizconfig-0.8.8 fails for me with MANY instances of errors like this: In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5/bits/stringfwd.h:40:0, from /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5/string:39, from /usr/include/unicode/std_string.h:33, from /usr/include/unicode/unistr.h:31, from /usr/include/unicode/strenum.h:14, from /usr/include/unicode/uenum.h:24, from /usr/include/unicode/ucnv.h:51, from /usr/include/libxml2/libxml/encoding.h:31, from /usr/include/libxml2/libxml/parser.h:810, from /usr/include/libxslt/transform.h:15, from compiz.cpp:39: /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5/bits/memoryfwd.h:63:3: error: template with C linkage template<typename> ^ The files involved here belong to the following packages: libxslt/transform.h - dev-libs/libxslt-1.1.29-r1 libxml2/libxml/*.h - dev-libs/libxml2-2.9.4-r1 unicode/*.h - dev-libs/icu-57.1 g++-v5/* - sys-devel/gcc-5.3.0 So the file compiz.cpp wraps all includes for C-style headers into one big extern "C" { … } block. I've known situations where such a thing helped resolve issues with C headers that weren't written with C++ in mind, so this does sound a reasonable thing to do, but appears to be incorrect here. Judging from the comment at the head of the file, ucnv.h is meant to describe the C API of ICU. In uenum.h I read this interesting section: #if U_SHOW_CPLUSPLUS_API #include "unicode/strenum.h" #endif So theoretically the file should not expose its C++ API unless explicitely requested to do so. So where does the request come from? It does seem to come from utypes.h: /** * \def U_SHOW_CPLUSPLUS_API * @internal */ #ifdef __cplusplus # ifndef U_SHOW_CPLUSPLUS_API # define U_SHOW_CPLUSPLUS_API 1 # endif #else # undef U_SHOW_CPLUSPLUS_API # define U_SHOW_CPLUSPLUS_API 0 #endif I guess there are at least two ways to address this problem at the libcompizconfig end. 1. Move the includes outside the extern "C" block In bug #356095 which is essentially the same for a different package, the maintainers opted for this approach. The HOMEPAGE of the package looks rather dead to me, and in particular I couldn't get at the git repo there. But on GitHub there is a repository which has a year-old commit to address this issue by moving the includes, too: https://github.com/compiz-reloaded/libcompizconfig/commit/1e42ea0e629d6a013e6e 2. Add -DU_SHOW_CPLUSPLUS_API=0 to CXXFLAGS or CPPFLAGS As the flag is declared internal, there is no guarantee that this will do the right thing in future releases, but it sounds sane enough. And it's a particularly well suited as a quick workaround until the package gets fixed: CXXFLAGS="$(portageq envvar CXXFLAGS) -DU_SHOW_CPLUSPLUS_API=0" \ emerge -1 libcompizconfig I gave that latter approach a try, and the package compiled successfully for me.