[ This message is being sent to perl-xs@perl.org seeking suggestions, with a CC to inl...@perl.org as an FYI. ]
We have a situation with Inline::CPP wherein the module is failing to pass smoke testing when the compiler is g++ version 4.4.3 (though I think the issue probably goes back to 4.2.1). Here is an example of two failure reports: http://www.cpantesters.org/cpan/report/35702916-59fc-11e1-8417-42773f40e7b5 http://www.cpantesters.org/cpan/report/afd08dc8-59fb-11e1-8417-42773f40e7b5 The CPAN Testers Results Overview (statistical analysis) shows a strong correlation between g++ v4.4.3 and failure. http://analysis.cpantesters.org/solved?distv=Inline-CPP-0.34_002#conf%3Agccversion The error message that I think is most relevant from those reports looks like this: _01basic_t_5cd2b57.c:212: error: invalid use of ‘static’ in linkage specification There will be many of these messages -- one for each C++ function (or object method in this case) that fails to compile. As I've investigated a possible reason for this I keep bumping into explanations (on StackOverflow, Usenet, etc.) that there cannot be two storage class specifiers for any given function. In other words, in "Standard C++", you cannot have: extern "C" void static mysub ( int something ); Because both 'extern "C"' and 'static' are storage class specifiers. One workaround is this: extern "C" { void static mysub ( int something ); } Now frankly I don't know EU::ParseXS's code well at all, and haven't walked through it. But it seems like it probably should be wrapping static functions in an extern "C" { ...... } block rather than just prepending extern "C" The question might come up "Why are only two of a couple hundred smoke tests failing on this issue?" I think that the answer is that starting with g++ v4.1.2 this aspect of "Standard" C++ began to be enforced. I can't find any command-line flags to disable it, but it seems that it's a problem that will probably get worse as more g++ users migrate to newer versions. That said, I'm actually using a 4.4.x version of g++ on one of my systems and cannot duplicate the failure... bad luck for me, I guess; I'd really like to personally get my hands on a failure so that I can try to fix it locally first. It's entirely possible that I'm barking up the wrong tree. When using Inline::CPP there are many layers involved that separate user code from final product. Inline::CPP subclasses Inline::C, and uses Inline (as does Inline::C). They rely on Parse::RecDescent, and Inline relies on ExtUtils::ParseXS. It's possible I've missed something in Inline::CPP's code, or in how Inline::C and Inline deal with the Inline::CPP. But there's one module that is ultimately connected with the .c output from the .xs output of Inline, and that's EU::ParseXS, and that module is the one generating the actual 'extern "C"' linkage modifier, so here I am. If anyone has any idea on what should happen next... whether EU::ParseXS needs some help, or whether I should be digging more into Inline::CPP and Inline's source, I'd appreciate some suggestions. Dave Oswald -- David Oswald daosw...@gmail.com dav...@cpan.org
