building yocto, autom4te fails

[MLeis4]

I've seen this in the kernel log (I'm using a ubuntu 14.04 machine now):

[1594600.398246] autom4te[19644]: segfault at 1 ip 00002b68e2af17fe sp 00007fff412430a0 error 4 in Dumper.so[2b68e2aea000+8000]

[1595466.635979] autom4te[2183]: segfault at 1 ip 00002b5373ec27fe sp 00007ffe5b127220 error 4 in Dumper.so[2b5373ebb000+8000]

[1596626.048546] autom4te[15535]: segfault at 1 ip 00002af6a13277fe sp 00007ffe4a96ceb0 error 4 in Dumper.so[2af6a1320000+8000]

This is on a ww25.5-15 build. From what I understand its because we're mixing perl version (the Dumper.so in the tree is from perl 5.20.0, 5.18 is on the system). I guess its using the "installed perl" instead of a "special perl".

Is this a problem? Should I install perl-5.20 on the host system someplace (if I put it first on my path, would it use that perl instead of /usr/bin/perl?)

[idata]

Hi martyl,

Having different perl version can cause an issue. It's recommended you use the latest Edison image and have the same version in your host system as well.The latest image can be downloaded here https://software.intel.com/en-us/iot/hardware/edison/downloads https://software.intel.com/en-us/iot/hardware/edison/downloads-Sergio

[MLeis4]

I installed perl 5.20 in /usr/local/bin/perl

Yet the builds keep insisting on /usr/bin/perl -- I have /usr/local/bin first in my path:

: leisner@y50 01:11:27;type -a perl

perl is /usr/local/bin/perl

perl is /usr/bin/perl

Ubuntu 15.04 doesn't have this problem (it has perl 5.20) yet I get a warning:

WARNING: Host distribution "Ubuntu-15.04" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that yo

u use a tested distribution.

Ubuntu 14.04 is supposedly "validated" but it has perl 5.18, which throws:

[1110811.178322] autom4te[3778]: segfault at 1 ip 00007fa706f767fe sp 00007fffd60c4ef0 error 4 in Dumper.so[7fa706f6f000+8000]

So:

a) how do I say to use /usr/local/bin/perl instead of /usr/bin/perl

b) how much of a problem are these segfaults? Why doesn't the build "stop" when they occur?

[idata]

1. Do you refer to the –l option of perl? You can see in http://linux.die.net/man/1/perl http://linux.die.net/man/1/perl that you can use this option to look for include files.
2. I've never received this message before, but by the looks of https://www.gnu.org/software/autoconf/manual/autoconf-2.66/html_node/Autom4te-Cache.html https://www.gnu.org/software/autoconf/manual/autoconf-2.66/html_node/Autom4te-Cache.html it doesn't seem to be crucial.

-Sergio

[idata]

Do you still need help with this thread, did you find our latest suggestion useful?

-Sergio

[MLeis4]

What perl are you using?

On various machines (ubuntu 14.04, mint 17) which use perl 5.18 this occurs.

On ubuntu 15.04 (which is using perl 5.20) its not.

The builds don't stop, and when a development tool core dumps I have doubts about the results.

I've seen it insists on using /usr/bin/perl, my /usr/local/bin/perl (first on my path) is 5.20.

I wonder if there's a way to tell EVERYTHING to use /usr/local/bin/perl.

I'm looking into this some more.

[idata]

We're using Ubuntu 14.04 that has perl 5.18 in /usr/bin. It seems we're seeing the same behavior as you. Let us know if you have any updates.

-Sergio

[MLeis4]

Thanks for the concurrence.

So when a build kicks off, and we think "ubuntu 14.04" is a validated system, its not really.

When I build on ubuntu 15.04, I don't see the problem.

This core dumps (I tracked them, some occur configurring intltool) probably are handled by the configuration silently -- but builds that produce core dumps bother me (and when building a product you find "some weird happens" in the field). I never like systems where you have to distinguish between "acceptable" problems and "unacceptable" problems.

[idata]

If you don't have issues on Ubuntu 15.04 then continue developing your project in that release. The "Ubuntu-15.04" has not been validated…" message is a warning, not an error so there's good chance that you never encounter unexpected failures. If you do, don't hesitate to contact us back.

-Sergio