Thanks.  Good information.  I guess I'll have to come up with a plan
for eliminating 'extern "C"' on a "per-function" basis, and for
wrapping the entire content of C++ code in one big 'extern "C" { .....
}' block.  I have a bad feeling on this: Could be that I'll break a
lot of compilers in the process.

I'm quickly losing respect for individuals who claim that Perl has too
many quirks.  Such opinions can only exist in the vacuum of ignorance
of just how quirky other [flexible and powerful] popular languages
tend to be.

Thanks for the tip... Not sure how I'll implement it, but it will go
on the TO-DO list.

On Tue, Feb 21, 2012 at 3:59 PM, Patrick LeBoutillier
<patrick.leboutill...@gmail.com> wrote:
> David,
>
> For the last 2 cases, see here:
> http://stackoverflow.com/questions/6312998/non-extern-function-with-c-linkage
>
> It seems some of the generated code has syntax that is no longer valid
> under a recent g++.
>
> Patrick
>
> On 2/21/12, David Oswald <daosw...@gmail.com> wrote:
>> The great thing about how Chris Williams runs his smokers is that he
>> rotates through what seems to be hundreds of different operating
>> systems / configurations.  I don't know how he does it.  But his smoke
>> tests really help us to find issues that need to be fixed.
>>
>> We have results back on 121 smoke tests for Inline::CPP v0.34_002.
>> There are no Darwin or MirBSD failures, although I would like to see a
>> few more tests from those two systems to be sure.  I think they're
>> fixed though.
>>
>> Of the first 121 tests to come in, we have six failures.  Two are for
>> some seemingly average Linux system.  Four are from NetBSD systems.
>>
>>
>>
>>
>> Here are links to the NetBSD reports (I think that will probably be
>> the easier one to solve, and I'm all about making the biggest impact
>> first).
>>
>> http://www.cpantesters.org/cpan/report/03e05dda-5beb-11e1-bf5e-8a22db34f026
>> http://www.cpantesters.org/cpan/report/ee72ddf4-5be2-11e1-a48f-e7fb434ae6f1
>> http://www.cpantesters.org/cpan/report/2731a314-5b34-11e1-a48f-e7fb434ae6f1
>> http://www.cpantesters.org/cpan/report/49ed1f5a-5a94-11e1-a48f-e7fb434ae6f1
>>
>> Probably a library issue.  It will be easy enough to add a 'special
>> case' to Makefile.PL if I just knew what defaults to set... which I
>> don't.
>>
>>
>>
>>
>> Here are links to the two Linux failures:
>>
>> http://www.cpantesters.org/cpan/report/35702916-59fc-11e1-8417-42773f40e7b5
>> http://www.cpantesters.org/cpan/report/afd08dc8-59fb-11e1-8417-42773f40e7b5
>>
>> These ones are more interesting, but probably more difficult.  They
>> demonstrate an issue we saw a couple months ago.  At that time there
>> were bigger fish to fry, and we never really got to the bottom of it.
>>
>>
>>
>>
>> If anyone has any insight (or even wild speculation) that might be
>> worth looking into I'd love to hear.  We've got Inline::CPP passing
>> 95%+ of the smokers.  I doubt we'll ever see 100% over a large set of
>> smoke tests (there will always be a new configuration that catches us
>> by surprise), but solving these two issues will get us close.
>>
>>
>> --
>>
>> David Oswald
>> daosw...@gmail.com
>>
>
> --
> Sent from my mobile device
>
> =====================
> Patrick LeBoutillier
> Rosemère, Québec, Canada



-- 

David Oswald
daosw...@gmail.com

Reply via email to