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 -- David Oswald daosw...@gmail.com
