ExtUtils::ParseXS can generate invalid C++

[David Oswald]

[ This message is being sent to perl-xs-***@public.gmane.org seeking suggestions,
with a CC to inline-***@public.gmane.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

[Sisyphus]

----- Original Message -----
From: "David Oswald" <daoswald-***@public.gmane.org>
To: <perl-xs-***@public.gmane.org>
Cc: <inline-***@public.gmane.org>
Sent: Friday, February 24, 2012 7:01 PM
Subject: ExtUtils::ParseXS can generate invalid C++

Post by David Oswald
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
http://www.cpantesters.org/cpan/report/35702916-59fc-11e1-8417-42773f40e7b5

Can't reproduce the problem.
I've tried gcc versions 4.7.0, 4.5.2, 4.4.7, and 4.4.3 on various builds of
perl (all on MS Windows).

In each case I was building 0.34_002, with Inline-0.50_01 and
Parse-RecDescent-1.67006 - same as the above tester.

I reckon I've seen similar before, and just assumed it must be the result of
some locale setting.

Cheers,
Rob

[David Mertens]

Hey David -

Looking over the perl-xs mailing list history, I see somebody inquiring
about C++ and XS, with a suggestion to look at this: p3rl.org/ExtUtils::XSpp

I'm not suggesting that you switch over to using EU::XSpp, but I thought
the additional point of reference might be helpful. Perhaps adding a link
in the See Also section would be good, too.

David

Post by Sisyphus
Sent: Friday, February 24, 2012 7:01 PM
Subject: ExtUtils::ParseXS can generate invalid C++

Post by David Oswald
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
http://www.cpantesters.org/**cpan/report/35702916-59fc-**
11e1-8417-42773f40e7b5<http://www.cpantesters.org/cpan/report/35702916-59fc-11e1-8417-42773f40e7b5>

Can't reproduce the problem.
I've tried gcc versions 4.7.0, 4.5.2, 4.4.7, and 4.4.3 on various builds
of perl (all on MS Windows).
In each case I was building 0.34_002, with Inline-0.50_01 and
Parse-RecDescent-1.67006 - same as the above tester.
I reckon I've seen similar before, and just assumed it must be the result
of some locale setting.
Cheers,
Rob