Sorting out one class of smoke test failure for Inline::CPP

[David Oswald]

There is one type of smoke-test error I'm seeing. I'll point out
examples from 0.38_002 since it uses the Makefile.PL logic that we've
been working on for so long. As mentioned before, 0.38_003 is more of
a "what-if", and is helping me to identify possible fixes in other
areas.

Ok, here are a few smoke test reports that exemplify the issue:

http://www.cpantesters.org/cpan/report/77318040-6df0-11e1-a48f-e7fb434ae6f1
http://www.cpantesters.org/cpan/report/09eaadb2-69af-11e1-a07f-3767a7e3bad1
http://www.cpantesters.org/cpan/report/482dae22-68e1-11e1-8a22-159ea7e3bad1

These each have an error that states something like this:

undefined symbol: _ZNSt8ios_base4InitD1Ev at /home/src/perl/repoperls/.......

I've googled a few links on the topic:

http://stackoverflow.com/questions/3347774/dynamic-linking-a-library-successful-when-executable-is-built-same-setup-fail
http://www.trilithium.com/johan/2005/06/static-libstdc/

One place I read mentioned that the fix was to specify that the linker
include libstdc++. So that brings me to Inline::CPP version 0.38_003.
Here's another fail:

http://www.cpantesters.org/cpan/report/01b0da7c-76d9-11e1-b744-2613173997d5

Same failure point. All new Makefile.PL (using ExtUtils::CppGuess).
The reason I point to this report is because you'll find in all of the
0.38_003 reports diagnostic information from test 08cppguess.t that
tells us which compiler and libraries are being selected in
Makefile.PL. It can be seen that we are indeed linking with
libstdc++.

I'm wondering if the sort of logic we're applying to 'darwin' should
be expanded to the more general linux cases:

if ($Config{osname} eq 'darwin'){
my $stdlib_query =
'find /usr/lib/gcc -name "libstdc++*" | grep $( uname -p )';
my $stdcpp =
`$stdlib_query`; + $stdcpp =~ s/^(.*)\/[^\/]+$/$1/;
$cc_guess = 'g++';
$libs_guess = "-L$stdcpp -lstdc++";

But as usual, I'm looking for suggestions that will target this
specific failure.

Dave

[Sisyphus]

----- Original Message -----
From: "David Oswald"

Post by David Oswald
One place I read mentioned that the fix was to specify that the linker
include libstdc++. So that brings me to Inline::CPP version 0.38_003.
http://www.cpantesters.org/cpan/report/01b0da7c-76d9-11e1-b744-2613173997d5
Same failure point. All new Makefile.PL (using ExtUtils::CppGuess).
The reason I point to this report is because you'll find in all of the
0.38_003 reports diagnostic information from test 08cppguess.t that
tells us which compiler and libraries are being selected in
Makefile.PL. It can be seen that we are indeed linking with
libstdc++.

Yes, but does libstdc++ get found ? If not, EU::MM will silently remove the
link (unless a noisy build is requested - in which case you'll see a warning
that the library could not be found).

I::CPP always includes the -lstdc++ link for me on Windows/MinGW - but the
library doesn't get found. This doesn't matter (since it's apparently not
needed).
Whenever I build "noisy" I see:

Starting Build Compile Stage
Starting "perl Makefile.PL" Stage
Note (probably harmless): No library found for -lstdc++
Writing Makefile for try_pl_2608
Writing MYMETA.yml and MYMETA.json
Finished "perl Makefile.PL" Stage

But if I have a successful build without "noisy" turned on, I see nothing
that indicates that libstdc++ was not found.

(Note that if EU::MM fails to find a library, it also automatically removes
the link to that library, thereby preventing the build from failing. This is
a great convenience when you know that you have to link to either libone or
libtwo, but don't which of the 2 libs will be found on the users machine.
You just do '-lone -ltwo' and EU::MM takes care of the rest.)

Cheers,
Rob