From: Gary Thomas <gary@mlbassoc.com>
To: openembedded-core@lists.openembedded.org
Subject: Re: Problems with perl 5.22
Date: Tue, 15 Mar 2016 09:00:11 +0100 [thread overview]
Message-ID: <56E7C10B.6000301@mlbassoc.com> (raw)
In-Reply-To: <E219D57B-2F63-40DE-9C33-161AE6F738CC@gmail.com>
On 03/10/2016 04:54 PM, Jens Rehsack wrote:
>
>> Am 10.03.2016 um 06:13 schrieb Gary Thomas <gary@mlbassoc.com>:
>>
>> I'm working on a package (amanda - the Advanced Maryland Archiving
>> system) that is written heavily in perl with swig interfaces to C.
>> This code ran great until the update to perl 5.22; it now dies a
>> horrible death on almost every activity. These failures seem to
>> always be in the swig generated wrappers, but that may just be
>> where most of the work gets done.
>>
>> I've narrowed this down to exactly the change to perl 5.22 from
>> 5.20. Using bisect as well as experimentation (e.g. trying all
>> the compiler combinations that have occurred since a last good
>> version) and I can go from working to failing by only the change
>> in perl.
>>
>> The interesting (scary) thing is that I've built amanda for my
>> target natively on my board running debian, including perl 5.22.
>> This means I can't say definitively that perl 5.22 is the culprit
>> as on debian it runs fine. So, it's got something to do with the
>> OE environment/porting/packaging of perl and not just the revision.
>>
>> I've also tested this on multiple architectures (ARM, PowerPC) with
>> the same results - with perl 5.20 amanda works, with perl 5.22 it fails.
>>
>> I've compared the actual 5.22.1 sources used by OE-core and debian
>> and they are subtly different, although I can't pinpoint any change
>> that might be responsible.
>>
>> For the moment, I can just fall back to perl 5.20 for my target
>> that needs to run amanda, but this isn't a real solution (e.g.
>> in this state I can't propose my recipe to any layer as it's
>> totally broken with the current OE-core). I'd like to see this
>> fixed but the amanda code (swig wrappers) are horribly complex
>> which makes debugging quite the challenge, not to mention they
>> may be about the only way to uncover the bug, whether it's in
>> amanda or perl.
>>
>> Any suggestions on how to move forward?
>
> Since I have no clue what's wrong and how it fails (backtrace
> would point in some directions), several ideas might work:
>
> How clean is your build location (we realize that often between
> updates some files remain in our target images until we wipe
> tmp/ - cleansstate for image doesn't help ...)?
>
> Did you prove the library path's of your *.so's? Perl does
> almost everything within libperl.so - build against wrong version
> causes in weird crashes (scan DBI mailing list for admin's
> build issues of DBI on AIX/HP-UX ...).
>
> Maybe share your recipe can help to reproduce the problem
> elsewhere and debug locally.
I've spent quite a lot of time trying to come up with debuggable
scenario(s) on many different targets. This is all packed up in
https://github.com/GaryThomas/meta-amanda
If you give the README a look, you'll see that there are plenty
of issues to be looked at.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
prev parent reply other threads:[~2016-03-15 8:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-10 5:13 Problems with perl 5.22 Gary Thomas
2016-03-10 15:54 ` Jens Rehsack
2016-03-10 16:00 ` Gary Thomas
2016-03-10 18:51 ` Stephen Arnold
2016-03-11 7:21 ` Khem Raj
2016-03-15 8:00 ` Gary Thomas [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56E7C10B.6000301@mlbassoc.com \
--to=gary@mlbassoc.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.