Inline::CPP portability concerns

[David Oswald]

I recently received a patch that makes Inline::CPP compatible with FreeBSD
versions 10 or newer. FreeBSD, as of v10 switched from g++ to clang++ as
the C++ compiler. Thank you to Graham Ollis for the RT report and the
patch(es) to fix it.

I'm still seeing considerable challenges for what appears to be vanilla
GNU/Linux. I cannot replicate them on any of my Ubuntu systems. But
anyone looking at the CPAN testers FAIL reports will see that a large
percentage of Linux tests are coming back as FAILs.

See the graph at http://static.cpantesters.org/distro/I/Inline-CPP.html for
an example, and click on any of the FAILs to see an example report.

The CPAN Testers Analytics don't seem (to me) to be pointing to anything
useful as the problem:
http://analysis.cpantesters.org/solved?distv=Inline-CPP-0.48

If there's anyone on the Inline list who is able to replicate the failure,
I would really appreciate your feedback and hopefully insight.

One thing that I have considered is that many Linux distros (including
mine) don't come with the g++ front end to the GNU compiler installed by
default. I don't think that's the issue we're seeing, but just to play it
safe I could execute "which g++" in Makefile.PL for any system that
professes to use the GNU toolchain, and if that comes up empty, I can die
with a useful configuration message. I guess that can't hurt, but I'm not
convinced that it would get me any closer to resolving the problem.

Hoping for a miracle (since this level of madness is nearly
indistinguishable from magic;)

Dave

[Eric Wilhelm]

Post by David Oswald
One thing that I have considered is that many Linux distros (including
mine) don't come with the g++ front end to the GNU compiler installed
by default.

Hi Dave,

That would be my guess but I haven't seen an error message which
indicates this.

http://www.cpantesters.org/distro/I/Inline-CPP.html

The fail reports there all seem to involve faulty assumptions attempting
to rmdir, unlink, or similar operations on the fs.

"mv: cannot ...", "Directory not empty", "No such file or directory",
"Can't open Makefile for input: No such file or directory"

These all probably relate to failing to check a return from a prior
system operation or system/backtick call. Some of that may be in the
core Inline but IIRC Inline::CPP had quite a lot of borrowed code, so
you might just be lacking fixes which have gone into Inline::C after the
copy-pasting.

"Perl API version v5.19.7 of _02basic_t_bc900f6 does not match v5.18.0"

That one sounds like a specific issue involving the tester's setup/env.
It may or may not be worth trying to detect/workaround that case.

Many of the smoke testers are willing to help diagnose the problem or
give you more details about how they have it setup if you contact them
directly.

--Eric

[s***@public.gmane.org]

From: David Oswald
Sent: Sunday, February 02, 2014 5:08 AM

Post by David Oswald
If there's anyone on the Inline list who is able to replicate the failure,
I would really appreciate your feedback and hopefully insight.

I can't reproduce the failure - I suspect you need a smoker for that.

Andreas Koenig runs most (if not all) of those 3.10-3-amd64 boxes - some of
which PASS, others of which FAIL.

Maybe ask *him* what accounts for the difference. (He generally responds -
though not always immediately.)

Specifically, I would give him the example that the following is a FAIL:

5.18.2 Linux 3.10-3-amd64 x86_64-linux-thread-multi-ld
osname=linux, osvers=3.12-1-amd64, archname=x86_64-linux-thread-multi-ld
uname='linux k83 3.12-1-amd64 #1 smp debian 3.12.6-2 (2013-12-29) x86_64
gnulinux '
at:
http://www.cpantesters.org/cpan/report/dccb2306-8b09-11e3-a1d3-12675d7e0655

yet the following is a PASS:

5.18.1 Linux 3.10-3-amd64 x86_64-linux-thread-multi-ld
osname=linux, osvers=3.12-1-amd64, archname=x86_64-linux-thread-multi-ld
uname='linux k83 3.12-1-amd64 #1 smp debian 3.12.6-2 (2013-12-29) x86_64
gnulinux '
at:
http://www.cpantesters.org/cpan/report/acdd5866-8b0a-11e3-9551-ff515d7e0655

Both reports come from Andreas, and both report the same version of gcc (ie
4.8.2).
Both reports quote the same osname.
Both reports quote the same archname.
Both reports quote the same uname.
How does he account for the discrepancy in results ?

The only difference I can see is in the version of perl itself - 5.18.1 for
the PASS, and 5.18.2 for the FAIL. (Hard to believe that accounts for the
different result.)

Cheers,
Rob