On 2016-03-23 06:36, Khem Raj wrote:
On Tue, Mar 22, 2016 at 9:53 PM, Gary Thomas <g...@mlbassoc.com> wrote:
I hope this is the correct place to discuss this problem. It
is all about a difference in behavior between a program built
using bitbake/OE (only OE-core is needed) vs building the program
on the target hardware itself.
I've been struggling with this problem since perl was upgraded
to version 5.22. I'm working on Amanda (Advanced Maryland Archive
tool) which is written primarily in perl and uses swig interfaces
to access native C functions. This code works great when using
the previous perl (5.20.x) but fails on all 32 bit targets with
perl 5.22
The interesting thing is that if I build Amanda on my target
directly (using SDK tools), it works perfectly even with perl
5.22, so it seems that there is some [subtle] difference between
building using bitbake/OE than when built on the self-hosted
target. I've compared the builds and the only thing I could
find (from the output of configure) is a difference in sizeof(off_t)
Sadly, when I tried to adjust this in the OE build, it didn't
make any difference, but perhaps I didn't make this change
correctly or completely.
do you have largefile support turned on ? if you do then it might
be detecting it wrongly during configure since we cache it to a
non-largefile case
so try to add something like
EXTRA_OECONF += "${@bb.utils.contains('DISTRO_FEATURES', 'largefile',
'ac_cv_sizeof_off_t=8', '', d)}"
while building perl or the affected program and see if that helps
Thanks for the idea, but that didn't help. I also forced some CFLAGS
to match, in particular:
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
but this didn't make any difference either.
Anyway, I'm looking for some help to solve this. I've put
all the relevant pieces and notes about the process at:
https://github.com/GaryThomas/meta-amanda.git
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
