about this part: [22:58:31] <Zorry> blueness: the gcc-plugins fail [22:58:33] <blueness> 4.7 just hit the overlay, i can try after the meeting [22:58:37] <blueness> i figured [22:58:52] <blueness> do you know what the breakage is? [22:59:42] <Zorry> gcc-4.7 have change some of the plugins api
the problem is that with gcc 4.7 they made the first step towards moving the gcc codebase to C++ in that 4.7 can be built both with a C and a C++ compiler (e.g., gcc/g++, see https://bugs.gentoo.org/show_bug.cgi?id=409315#c7). this affects the plugin API because of C++ name mangling so plugins have to be built with the same kind of compiler as gcc itself. C++ itself poses a problem as well in that certain C constructs such as designated initializers cannot be used (even though they are very useful for initializing some structures that all plugins need). in any case building plugins for gcc 4.7 requires two things: 1. detect the compiler used to build gcc 2. use that same compiler to build the plugin the first problem can be solved by checking whether ENABLE_BUILD_WITH_CXX is defined in auto-host.h, a header available to plugins. the second problem is harder because the kernel make system has very little support to build userland code (such as gcc plugins) with a C++ compiler. incidentally, while working with gcc trunk on LTO last year i'd already run across this C++ build issue but i have yet to finish the linux-side support infrastructure because in the meantime i figured i could just use the old C build mechanism for gcc (if you check the plugins, some of them already have 4.7 dependent code in them so i know they all work fine with gcc 4.7 in fact). so in the short term, if you want gcc 4.7 and PaX plugin support, make sure you build gcc with a C compiler and maybe voice your opinion in the above mentioned bug ;).
