[PATCH][meta-fsl-arm] 2.6.35 kernel build error with perl 5.22

[PATCH][meta-fsl-arm] 2.6.35 kernel build error with perl 5.22

[Stephen Arnold]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

When building fsl-image-machine-test for imx28-evk with n00b defaults
using the fsl-community-bsp repo manifest thing, it fails on the old
kernel in meta-fsl-arm/recipes-kernel/linux/linux-imx_2.6.35.3.bb.

There are a few things questionable/wrong here:

1) It uses the build host perl, which is why it fails here and not in
the upstream builder.

2) The dts file for the evk machine in 4.1 mainline looks complete
(along with several other imx28 machines) so why does it default to
such an old kernel?

3) Switching to newer kernel makes gst-fsl-plugins fail with the
"looking for kernel headers from user space" error because it can't
find the old framebuffer header (mxcfb.h).  It should depend on old
fsl kernel only.

4) The old kernel recipe should depend on perl-native.

The attached patch fixes the perl error in the the old kernel build
and the above test image completed fine with it.  Not an "official"
patch per se, just useful if you're stuck...

Steve

[-- Attachment #2: 0001_fix_kernel_timeconst_perl_array_error.patch --]
[-- Type: text/x-patch, Size: 313 bytes --]

diff --git a/kernel/timeconst.pl b/kernel/timeconst.pl
index eb51d76..8915419 100644
--- a/kernel/timeconst.pl
+++ b/kernel/timeconst.pl
@@ -370,7 +370,7 @@ if ($hz eq '--can') {
 	}
 
 	@val = @{$canned_values{$hz}};
-	if (!defined(@val)) {
+	if !(@val) {
 		@val = compute_values($hz);
 	}
 	output($hz, @val);

Re: [oe] [PATCH][meta-fsl-arm] 2.6.35 kernel build error with perl 5.22

[Otavio Salvador]

Hello Stephen,

(Adding meta-freescale mailing list as it is the proper place for this
discussion)

On Sat, Aug 15, 2015 at 3:05 AM, Stephen Arnold
<stephen.arnold42@gmail.com> wrote:
> When building fsl-image-machine-test for imx28-evk with n00b defaults
> using the fsl-community-bsp repo manifest thing, it fails on the old
> kernel in meta-fsl-arm/recipes-kernel/linux/linux-imx_2.6.35.3.bb.
>
> There are a few things questionable/wrong here:
>
> 1) It uses the build host perl, which is why it fails here and not in
> the upstream builder.

The master branch has remove this old version; it now uses linux-fslc
for mx23, mx28, mx5 SoCs.

> 2) The dts file for the evk machine in 4.1 mainline looks complete
> (along with several other imx28 machines) so why does it default to
> such an old kernel?

In fido it is used but dropped in next release.

I want to understand why it failed on your system as it works in the
autobuilder. What host distro are you using?

> 3) Switching to newer kernel makes gst-fsl-plugins fail with the
> "looking for kernel headers from user space" error because it can't
> find the old framebuffer header (mxcfb.h).  It should depend on old
> fsl kernel only.

Yes and we got this fixed dropping mx28 support from those. We now
rely on official GStreamer for those SoCs and stopped using Freescale
codecs (in master).

> 4) The old kernel recipe should depend on perl-native.

Adding perl-native dependency fixes it?

> The attached patch fixes the perl error in the the old kernel build
> and the above test image completed fine with it.  Not an "official"
> patch per se, just useful if you're stuck...

Is this needed if using perl-native?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH][meta-fsl-arm] 2.6.35 kernel build error with perl 5.22

[Otavio Salvador]

Hello Stephen,

(Adding meta-freescale mailing list as it is the proper place for this
discussion)

On Sat, Aug 15, 2015 at 3:05 AM, Stephen Arnold
<stephen.arnold42@gmail.com> wrote:
> When building fsl-image-machine-test for imx28-evk with n00b defaults
> using the fsl-community-bsp repo manifest thing, it fails on the old
> kernel in meta-fsl-arm/recipes-kernel/linux/linux-imx_2.6.35.3.bb.
>
> There are a few things questionable/wrong here:
>
> 1) It uses the build host perl, which is why it fails here and not in
> the upstream builder.

The master branch has remove this old version; it now uses linux-fslc
for mx23, mx28, mx5 SoCs.

> 2) The dts file for the evk machine in 4.1 mainline looks complete
> (along with several other imx28 machines) so why does it default to
> such an old kernel?

In fido it is used but dropped in next release.

I want to understand why it failed on your system as it works in the
autobuilder. What host distro are you using?

> 3) Switching to newer kernel makes gst-fsl-plugins fail with the
> "looking for kernel headers from user space" error because it can't
> find the old framebuffer header (mxcfb.h).  It should depend on old
> fsl kernel only.

Yes and we got this fixed dropping mx28 support from those. We now
rely on official GStreamer for those SoCs and stopped using Freescale
codecs (in master).

> 4) The old kernel recipe should depend on perl-native.

Adding perl-native dependency fixes it?

> The attached patch fixes the perl error in the the old kernel build
> and the above test image completed fine with it.  Not an "official"
> patch per se, just useful if you're stuck...

Is this needed if using perl-native?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [oe] [PATCH][meta-fsl-arm] 2.6.35 kernel build error with perl 5.22

[Stephen Arnold]

Sorry, I guess I said that on IRC but left it out of the email...

The failure is only with perl 5.22, and it doesn't matter whether it's
perl-native or the should-not-be-used-anyway build host perl (that's
what the patch is for).

It's only a warning in prior versions of perl, so you wouldn't see it
in either case above.

Steve

On Mon, Aug 17, 2015 at 2:59 AM, Otavio Salvador
<otavio.salvador@ossystems.com.br> wrote:
> Hello Stephen,
>
> (Adding meta-freescale mailing list as it is the proper place for this
> discussion)
>
> On Sat, Aug 15, 2015 at 3:05 AM, Stephen Arnold
> <stephen.arnold42@gmail.com> wrote:
>> When building fsl-image-machine-test for imx28-evk with n00b defaults
>> using the fsl-community-bsp repo manifest thing, it fails on the old
>> kernel in meta-fsl-arm/recipes-kernel/linux/linux-imx_2.6.35.3.bb.
>>
>> There are a few things questionable/wrong here:
>>
>> 1) It uses the build host perl, which is why it fails here and not in
>> the upstream builder.
>
> The master branch has remove this old version; it now uses linux-fslc
> for mx23, mx28, mx5 SoCs.
>
>> 2) The dts file for the evk machine in 4.1 mainline looks complete
>> (along with several other imx28 machines) so why does it default to
>> such an old kernel?
>
> In fido it is used but dropped in next release.
>
> I want to understand why it failed on your system as it works in the
> autobuilder. What host distro are you using?
>
>> 3) Switching to newer kernel makes gst-fsl-plugins fail with the
>> "looking for kernel headers from user space" error because it can't
>> find the old framebuffer header (mxcfb.h).  It should depend on old
>> fsl kernel only.
>
> Yes and we got this fixed dropping mx28 support from those. We now
> rely on official GStreamer for those SoCs and stopped using Freescale
> codecs (in master).
>
>> 4) The old kernel recipe should depend on perl-native.
>
> Adding perl-native dependency fixes it?
>
>> The attached patch fixes the perl error in the the old kernel build
>> and the above test image completed fine with it.  Not an "official"
>> patch per se, just useful if you're stuck...
>
> Is this needed if using perl-native?
>
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH][meta-fsl-arm] 2.6.35 kernel build error with perl 5.22

[Stephen Arnold]

Sorry, I guess I said that on IRC but left it out of the email...

The failure is only with perl 5.22, and it doesn't matter whether it's
perl-native or the should-not-be-used-anyway build host perl (that's
what the patch is for).

It's only a warning in prior versions of perl, so you wouldn't see it
in either case above.

Steve

On Mon, Aug 17, 2015 at 2:59 AM, Otavio Salvador
<otavio.salvador@ossystems.com.br> wrote:
> Hello Stephen,
>
> (Adding meta-freescale mailing list as it is the proper place for this
> discussion)
>
> On Sat, Aug 15, 2015 at 3:05 AM, Stephen Arnold
> <stephen.arnold42@gmail.com> wrote:
>> When building fsl-image-machine-test for imx28-evk with n00b defaults
>> using the fsl-community-bsp repo manifest thing, it fails on the old
>> kernel in meta-fsl-arm/recipes-kernel/linux/linux-imx_2.6.35.3.bb.
>>
>> There are a few things questionable/wrong here:
>>
>> 1) It uses the build host perl, which is why it fails here and not in
>> the upstream builder.
>
> The master branch has remove this old version; it now uses linux-fslc
> for mx23, mx28, mx5 SoCs.
>
>> 2) The dts file for the evk machine in 4.1 mainline looks complete
>> (along with several other imx28 machines) so why does it default to
>> such an old kernel?
>
> In fido it is used but dropped in next release.
>
> I want to understand why it failed on your system as it works in the
> autobuilder. What host distro are you using?
>
>> 3) Switching to newer kernel makes gst-fsl-plugins fail with the
>> "looking for kernel headers from user space" error because it can't
>> find the old framebuffer header (mxcfb.h).  It should depend on old
>> fsl kernel only.
>
> Yes and we got this fixed dropping mx28 support from those. We now
> rely on official GStreamer for those SoCs and stopped using Freescale
> codecs (in master).
>
>> 4) The old kernel recipe should depend on perl-native.
>
> Adding perl-native dependency fixes it?
>
>> The attached patch fixes the perl error in the the old kernel build
>> and the above test image completed fine with it.  Not an "official"
>> patch per se, just useful if you're stuck...
>
> Is this needed if using perl-native?
>
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750