[yocto] Adding Fortran to Raspberrypi2

Fri Dec 9 13:30:51 PST 2016

Hi, 
I tried building on the target RPi2B.The config.log and the steps that I did are found at 
https://gist.github.com/develone/bfa03e975f173a07b9fcb22a4d817df6
I tried reporting the bug but the acct creation is restricted.Let me know if I can provide adding information,Thanks,
 Edward Vidal Jr. e-mail develone at sbcglobal.net 915-595-1613 

    On Friday, December 9, 2016 9:04 AM, "yocto-request at yoctoproject.org" <yocto-request at yoctoproject.org> wrote:

 Send yocto mailing list submissions to
    yocto at yoctoproject.org

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.yoctoproject.org/listinfo/yocto
or, via email, send a message with subject or body 'help' to
    yocto-request at yoctoproject.org

You can reach the person managing the list at
    yocto-owner at yoctoproject.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of yocto digest..."

Today's Topics:

  1. Adding Fortran to Raspberrypi2 (Edward Vidal)
  2. Re: Kernel config incremental modification not working.
      (Bruce Ashfield)
  3. Re: update mechanisms (Patrick Ohly)
  4. Re: update mechanisms (Stefano Babic)

----------------------------------------------------------------------

Message: 1
Date: Fri, 9 Dec 2016 13:28:35 +0000 (UTC)
From: Edward Vidal <develone at sbcglobal.net>
To: "yocto at yoctoproject.org" <yocto at yoctoproject.org>
Subject: [yocto] Adding Fortran to Raspberrypi2
Message-ID: <405620911.1114427.1481290115720 at mail.yahoo.com>
Content-Type: text/plain; charset="utf-8"

Hi

Trying to add fortran to 6.2.0 branch morty for a Raspberrypi2

Step 1 modified meta/recipes-devtools/gcc/gcc-6.2.inc
-FORTRAN = ""
+FORTRAN = ",fortran"
bitbake core-image-sato created the image 

Testing on target. I see fortran in the command gcc -v.

gcc -v --enable-languages=c,c++,fortran gcc version 6.2.0 (GCC)

With the command ./configure for octave.
checking whether a usable Fortran compiler was found... no
configure: error: A Fortran compiler is required

Step 2 Checking the mailing list.
??? |Hi
??? |
??? |On Mon, 8 Feb 2016 08:19:53 +0000
??? |"Liubchynskyi, Stanislav (Nokia - PL/Wroclaw)" <stanislav.liubchynskyi at nokia.com> wrote:
??? |
??? |> Hi,
??? |> I want to add fortran support to yocto build. I try different way whitch describe in the ethernet but enyone does't work. I use fido branch and gcc 4.9. Can you describe me step by step how to enable fortran in yocto or where I can find work instruction.
??? |> Thanks for help.

??? |Fortran support in gcc is disabled by default, to enable it add the following line to your config, then build the libgfortran package.

??? |FORTRAN_forcevariable = ",fortran"

??? |> 
??? |> 
??? |> 
??? |> Best regards,
??? |> 
??? |> Stanislav Liubchynskyi
??? |> Software Developer, LFS, OPSW Wroclaw
??? |> Mobile Broadband, Nokia Networks>? 

I added FORTRAN_forcevariable = ",fortran" to my config.? Still no fortran.

I added libgfortran to variable IMAGE_INSTALL_append and I get the following error
?
ERROR: oe_runmake failed

../../../../../../../../work-shared/gcc-6.2.0-r0/gcc-6.2.0/libgfortran/runtime/backtrace.c:37:33: fatal error: backtrace-supported.h: No such file or directory
?#include "backtrace-supported.h"
???????????????????????????????? ^
compilation terminated.

Thanks in advance,

?Edward Vidal Jr. e-mail develone at sbcglobal.net 915-595-1613
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20161209/644f3ef0/attachment-0001.html>

------------------------------

Message: 2
Date: Fri, 9 Dec 2016 08:37:47 -0500
From: Bruce Ashfield <bruce.ashfield at windriver.com>
To: Bent Bisballe Nyeng <xbbn at mjolner.dk>, "yocto at yoctoproject.org"
    <yocto at yoctoproject.org>
Subject: Re: [yocto] Kernel config incremental modification not
    working.
Message-ID: <1f6d8fc5-2853-072f-72d5-785c5bd783f1 at windriver.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed

On 2016-12-09 02:25 AM, Bent Bisballe Nyeng wrote:
> On 12/08/2016 05:06 PM, Bruce Ashfield wrote:
>> On 2016-12-08 09:06 AM, Bent Bisballe Nyeng wrote:
>>> Hi list
>>>
>>> I am working on a project based on the iMX6UL-EVK using the meta-fsl-arm
>>> layer for the kernel.
>>> In a local layer I have a bbappend recipe containing a patch for an
>>> extra kernel feature (a framebuffer device) in that kernel as well as a
>>> .cfg enabling said feature.
>>> The bbappend recipe is located in
>>> recipes-kernel/linux/linux-fslc-imx_%.bbappend and looks like this:
>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>
>>> SRC_URI += " \
>>>        file://0001-mxc-4.1.patch \
>>>        file://ST7789S.cfg \
>>> "
>>>
>>> KERNEL_DEVICETREE = "imx6ul-14x14-evk.dtb"
>>>
>>> The .cfg is located in recipes-kernel/linux/linux-fslc-imx/ST7789S.cfg
>>> and looks like:
>>> CONFIG_FB_MXS_ST7789S_QVGA=y
>>>
>>> The 0001-mxc-4.1.patch patch is correctly applied but the .cfg is either
>>> ignored or overwritten by some later buyild step since the resulting
>>> .config after kernel compilation contains:
>>> # CONFIG_FB_MXS_ST7789S_QVGA is not set
>>>
>>> I have tried finding the script in the build/.../temp folder that takes
>>> care of the .cfg file patching but have not been able to find anything
>>> useful.
>>>
>>> Any hints as to where I should start looking for a solution?
>> Fragment processing using the kernel tools + auditing is only currently
>> available to kernel recipes that use the kernel-yocto bbclass. That
>> opt-in requirement was to ensure that existing recipes and workflows
>> weren't broken by the new features.
>>
>> Last time I checked, the meta-fsl* kernel recipes don't use the
>> kernel-yocto bbclass, so the fragment would be ignored.
>>
>> I'm taking the processing of fragments and making it universally
>> available in the upcoming 2.3 release, so what I just described
>> won't be an issue for much longer.
>>
>> In the mean time, you have a few options:
>>
>>  - in your bbappend, add "inherit kernel-yocto" and the processing
>>    of fragments will be enabled (I can't say that I've tested
>>    it against that recipe .. but the entire point of the new tasks
>>    is that they are transparent/don't break existing worflows)
>>
>>  - carry a defconfig in your layer, and add it to the SRC_URI. That
>>    defconfig would be the existing kernel recipe's defconfig + your
>>    options
>>
>>  - write a custom task that runs before configuration to add your
>>    options (cat, merge, etc, etc).
>>
>> I wouldn't really suggest the custom task route, but it is a valid
>> option, so I put it in my list.
>>
>> The quickest is probably the defconfig option, and then the new
>> inherit. If you had issues with the inherit, I could lend a hand to
>> debug what is wrong .. since I'll run into it eventually with my
>> feature work for the 2.3 release.
> Hi Bruce
>
> Thanks for the reply.
>
> A quick test shows that the linux-fslc-imx recipe doesn't respond well
> to the 'inherit kernel-yocto' solution failing in the do_kernel_checkout
> task with a "Bad substitution" error message.
> So I think I will go with the defconfig solution until the release of 2.3.
> Any estimate of when 2.3 will be shipping? And do you know if this will
> by any chance include the upcoming 4.9 LTS kernel?

April 2017, and it will have the 4.9 kernel + 4.10 (unless 4.11 really
hurries along).

>
> If you would like some more info on the failing task I'll be happy to
> supply it.

If you put the configuration you are using (bblayers, MACHINE) in an
email and send it directly to me, I'll find time to poke at it, I'm
interested to understand why it failed.

bruce

>
> Thanks for your help :-)
>
> Kind regards
> Bent Bisballe Nyeng
>

------------------------------

Message: 3
Date: Fri, 09 Dec 2016 16:13:53 +0100
From: Patrick Ohly <patrick.ohly at intel.com>
To: Stefano Babic <sbabic at denx.de>, Kristian Amlie
    <kristian.amlie at mender.io>
Cc: "Lopez, Mariano" <mariano.lopez at intel.com>,
    yocto at yoctoproject.org, Andr? Draszik <git at andred.net>
Subject: Re: [yocto] update mechanisms
Message-ID: <1481296433.17535.170.camel at intel.com>
Content-Type: text/plain; charset="UTF-8"

Hello everyone!

Thanks for contributing directly to the page. It's great to see this
done collaboratively.

On Tue, 2016-12-06 at 23:38 +0100, Stefano Babic wrote:
> Hi Philip,
> 
> On 06/12/2016 19:45, Philip Balister wrote:
> > On 12/06/2016 06:11 AM, Lopez, Mariano wrote:
> >> I agree with you, that we need to have a section per project, the table
> >> is too limiting.
> > 
> > I just skimmed the page and the table format isn't working well with the
> > length of the blocks of text.
> > 
> 
> Agree - I think it is better to have a section per project.

That always has been the goal, and I now updated the page accordingly. I
tried to summarize the key aspects of each mechanism in the table
itself. That's something that I haven't seen elsewhere and something
that the page can  I tried to be as fair and objective as possible,
please shout if I messed something up or you don't agree with my
summary.

In particular the "complexity" column is a bit subjective. Stefano, I
hope you don't mind that I did not quite buy the "easy to use"
characterization of swupdate ;-) For a system that is as flexible as
swupdate, I'd expect a more difficult learning curve and some need to
customize the system before using it, so I added a "(but requires
customization!?)" comment to that statement.

Kristian, I added a comment that Mender requires U-Boot. That is
correct, isn't it? I understand that this restriction allows you to
implement things like automatic rollback, but it's worth mentioning that
this comes with that limitation.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

------------------------------

Message: 4
Date: Fri, 9 Dec 2016 17:03:10 +0100
From: Stefano Babic <sbabic at denx.de>
To: Patrick Ohly <patrick.ohly at intel.com>, Stefano Babic
    <sbabic at denx.de>,    Kristian Amlie <kristian.amlie at mender.io>
Cc: "Lopez, Mariano" <mariano.lopez at intel.com>,
    yocto at yoctoproject.org, Andr? Draszik <git at andred.net>
Subject: Re: [yocto] update mechanisms
Message-ID: <4515f6e0-a99b-09ae-e233-786ceed4847d at denx.de>
Content-Type: text/plain; charset=utf-8

Hi Patrick,

On 09/12/2016 16:13, Patrick Ohly wrote:
> Hello everyone!
> 
> Thanks for contributing directly to the page. It's great to see this
> done collaboratively.
> 
> On Tue, 2016-12-06 at 23:38 +0100, Stefano Babic wrote:
>> Hi Philip,
>>
>> On 06/12/2016 19:45, Philip Balister wrote:
>>> On 12/06/2016 06:11 AM, Lopez, Mariano wrote:
>>>> I agree with you, that we need to have a section per project, the table
>>>> is too limiting.
>>>
>>> I just skimmed the page and the table format isn't working well with the
>>> length of the blocks of text.
>>>
>>
>> Agree - I think it is better to have a section per project.
> 
> That always has been the goal, and I now updated the page accordingly.

Page is really better now :-)

> I
> tried to summarize the key aspects of each mechanism in the table
> itself. That's something that I haven't seen elsewhere and something
> that the page can  I tried to be as fair and objective as possible,
> please shout if I messed something up or you don't agree with my
> summary.
> 
> In particular the "complexity" column is a bit subjective. Stefano, I
> hope you don't mind that I did not quite buy the "easy to use"
> characterization of swupdate ;-)

No worry...and I have not written myself. It was inserted by Mariano, so
it looks like that swupdate at least for Mariano is "easy to use".
I think it is correct to point out that customization is required.

> For a system that is as flexible as
> swupdate, I'd expect a more difficult learning curve and some need to
> customize the system before using it, so I added a "(but requires
> customization!?)" comment to that statement.

Agree.

> 
> Kristian, I added a comment that Mender requires U-Boot. That is
> correct, isn't it? I understand that this restriction allows you to
> implement things like automatic rollback, but it's worth mentioning that
> this comes with that limitation.

Best regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

------------------------------

-- 
_______________________________________________
yocto mailing list
yocto at yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

End of yocto Digest, Vol 75, Issue 37
*************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20161209/4d83a98b/attachment.html>