Re: [gentoo-hardened] Meeting log from 2012-04-18 20:00 meeting.

[PaX Team]

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 ;).