subject:"\[yocto\] SDK"

Re: [yocto] SDK: getting error "xmlcatalog: not found" installing SDK

2019-08-09 Thread baisch

Hello everyone,

I was able to workaround this issue: 

In `conf/bblayers.conf` I put my custom layer ontop of the `meta` layer. Since 
classes seem to ignore the priority set by the layer config. Then I copied the 
`classes/xmlcatalog.bbclass` class to my layer and in the file I changed 
`xmlcatalog` to `${bindir}/xmlcatalog`.

I'm still not sure if this an error specific to my setup or a general issue 
which should be fixed. Also I was hoping there is a better solution since 
changes to the original `classes/xmlcatalog.bbclass` will always be overridden.

Regards,

- Michael
-- 


bai...@tau-tec.com wrote on 30.07.2019 16:32:
> Hello,
> 
> after updating to warrior 2.7.1 from thud and trying to install the
> Extensible
> SDK again I'm getting the following error:
> 
> ```
> ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Error executing a
> python
> function in exec_python_func() autogenerated:
> 
> The stack trace of python calls that resulted in this exception/failure
> was:
> File: 'exec_python_func() autogenerated', lineno: 2, function: 
>  0001:
>  *** 0002:do_build_native_sysroot(d)
>  0003:
> File:
> '/workdir/sdk/rpi/layers/poky/meta/recipes-core/meta/build-sysroots.bb',
> lineno: 23, function: do_build_native_sysroot
>  0019:
>  0020:python do_build_native_sysroot () {
>  0021: targetsysroot = d.getVar("STANDALONE_SYSROOT")
>  0022: nativesysroot = d.getVar("STANDALONE_SYSROOT_NATIVE")
>  *** 0023: staging_populate_sysroot_dir(targetsysroot, nativesysroot,
>  True, d)
>  0024:}
>  0025:do_build_native_sysroot[cleandirs] =
>  "${STANDALONE_SYSROOT_NATIVE}"
>  0026:do_build_native_sysroot[nostamp] = "1"
>  0027:addtask do_build_native_sysroot before do_build
> File: '/workdir/sdk/rpi/layers/poky/meta/classes/staging.bbclass', lineno:
> 235,
> function: staging_populate_sysroot_dir
>  0231: continue
>  0232:
>  0233: staging_processfixme(fixme, targetdir, targetsysroot,
>  nativesysroot, d)
>  0234: for p in postinsts:
>  *** 0235: subprocess.check_output(p, shell=True,
>  stderr=subprocess.STDOUT)
>  0236:
>  0237:#
>  0238:# Manifests here are complicated. The main sysroot area has the
>  unpacked sstate
>  0239:# which us unrelocated and tracked by the main sstate manifests.
>  Each
>  recipe
> File:
> '/workdir/sdk/rpi/buildtools/sysroots/x86_64-pokysdk-linux/usr/lib/python3.7/subprocess.py',
> lineno: 395, function: check_output
>  0391: # empty string. That is maintained here for backwards
>  compatibility.
>  0392: kwargs['input'] = '' if kwargs.get('universal_newlines', False)
>  else b''
>  0393:
>  0394: return run(*popenargs, stdout=PIPE, timeout=timeout,
>  check=True,
>  *** 0395: **kwargs).stdout
>  0396:
>  0397:
>  0398:class CompletedProcess(object):
>  0399: """A process that has finished running.
> File:
> '/workdir/sdk/rpi/buildtools/sysroots/x86_64-pokysdk-linux/usr/lib/python3.7/subprocess.py',
> lineno: 487, function: run
>  0483: raise
>  0484: retcode = process.poll()
>  0485: if check and retcode:
>  0486: raise CalledProcessError(retcode, process.args,
>  *** 0487: output=stdout, stderr=stderr)
>  0488: return CompletedProcess(process.args, retcode, stdout, stderr)
>  0489:
>  0490:
>  0491:def list2cmdline(seq):
> Exception: subprocess.CalledProcessError: Command
> '/workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog'
> returned non-zero exit status 127.
> 
> Subprocess output:
> /workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
> 5:
> /workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
> xmlcatalog: not found
> /workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
> 8:
> /workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
> xmlcatalog: not found
> ```
> 
> I believe the problem is that in the
> `postinst-docbook-xsl-stylesheets-native-xmlcatalog`, `xmlcatalog` is not
> an
> absolute path and thus not found.
> This can be traced to the new
> `layers/poky/meta/classes/xmlcatalog.bbclass`. I
> tried to change `xmlcatalog` to `${SYSROOT_DESTDIR}${bindir}/xmlcatalog`
> there,
> but even after cleaning the `docbook-xsl-stylesheets` recipe this change
> had no
> effect. I'm not sure if this class is cached somewhere else or something.
> 
> Can someone help me getting the SDK to work again, and maybe this is
> general
> thing with needs to be fixed?
> 
> 
> Thank you.
> 
> Regards,
> 
> - Michael
> -- 
> 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> 
> 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listi

[yocto] SDK: getting error "xmlcatalog: not found" installing SDK

2019-07-30 Thread baisch

Hello,

after updating to warrior 2.7.1 from thud and trying to install the Extensible 
SDK again I'm getting the following error:

```
ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Error executing a python 
function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:do_build_native_sysroot(d)
 0003:
File: '/workdir/sdk/rpi/layers/poky/meta/recipes-core/meta/build-sysroots.bb', 
lineno: 23, function: do_build_native_sysroot
 0019:
 0020:python do_build_native_sysroot () {
 0021:targetsysroot = d.getVar("STANDALONE_SYSROOT")
 0022:nativesysroot = d.getVar("STANDALONE_SYSROOT_NATIVE")
 *** 0023:staging_populate_sysroot_dir(targetsysroot, nativesysroot, True, 
d)
 0024:}
 0025:do_build_native_sysroot[cleandirs] = "${STANDALONE_SYSROOT_NATIVE}"
 0026:do_build_native_sysroot[nostamp] = "1"
 0027:addtask do_build_native_sysroot before do_build
File: '/workdir/sdk/rpi/layers/poky/meta/classes/staging.bbclass', lineno: 235, 
function: staging_populate_sysroot_dir
 0231:continue
 0232:
 0233:staging_processfixme(fixme, targetdir, targetsysroot, 
nativesysroot, d)
 0234:for p in postinsts:
 *** 0235:subprocess.check_output(p, shell=True, 
stderr=subprocess.STDOUT)
 0236:
 0237:#
 0238:# Manifests here are complicated. The main sysroot area has the 
unpacked sstate
 0239:# which us unrelocated and tracked by the main sstate manifests. Each 
recipe
File: 
'/workdir/sdk/rpi/buildtools/sysroots/x86_64-pokysdk-linux/usr/lib/python3.7/subprocess.py',
 lineno: 395, function: check_output
 0391:# empty string. That is maintained here for backwards 
compatibility.
 0392:kwargs['input'] = '' if kwargs.get('universal_newlines', 
False) else b''
 0393:
 0394:return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
 *** 0395:   **kwargs).stdout
 0396:
 0397:
 0398:class CompletedProcess(object):
 0399:"""A process that has finished running.
File: 
'/workdir/sdk/rpi/buildtools/sysroots/x86_64-pokysdk-linux/usr/lib/python3.7/subprocess.py',
 lineno: 487, function: run
 0483:raise
 0484:retcode = process.poll()
 0485:if check and retcode:
 0486:raise CalledProcessError(retcode, process.args,
 *** 0487: output=stdout, stderr=stderr)
 0488:return CompletedProcess(process.args, retcode, stdout, stderr)
 0489:
 0490:
 0491:def list2cmdline(seq):
Exception: subprocess.CalledProcessError: Command 
'/workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog'
 returned non-zero exit status 127.

Subprocess output:
/workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
 5: 
/workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
 xmlcatalog: not found
/workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
 8: 
/workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
 xmlcatalog: not found
```

I believe the problem is that in the 
`postinst-docbook-xsl-stylesheets-native-xmlcatalog`, `xmlcatalog` is not an 
absolute path and thus not found.
This can be traced to the new `layers/poky/meta/classes/xmlcatalog.bbclass`. I 
tried to change `xmlcatalog` to `${SYSROOT_DESTDIR}${bindir}/xmlcatalog` there, 
but even after cleaning the `docbook-xsl-stylesheets` recipe this change had no 
effect. I'm not sure if this class is cached somewhere else or something.

Can someone help me getting the SDK to work again, and maybe this is general 
thing with needs to be fixed?


Thank you.

Regards,

- Michael
-- 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK build fails at latest thud

2019-05-08 Thread Teemu K

Done. Hopefully it went to right place.

I noticed that core-image-minimal does not fail, but if you add for
example 'bash' to it, it fails like it does on my image.

t. Teemu

On Tue, May 7, 2019 at 11:57 PM akuster808  wrote:
>
> Teemu,
>
>
>
> On 5/1/19 11:50 PM, Teemu K wrote:
> > On Thu, Mar 28, 2019 at 6:36 AM Teemu K  wrote:
> >> On Mon, Mar 18, 2019 at 7:21 AM Teemu K  wrote:
> >>> On Fri, Mar 15, 2019 at 2:17 AM akuster  wrote:
> 
> 
>  On 3/13/19 9:50 PM, Teemu K wrote:
> 
>  Hi,
> 
>  I noticed that when trying to build sdk on thud it fails on latest
>  version. Actually it broke somewhere between commits:
> 
>  1cab405d88149fd63322a867c6adb4a80ba68db3 (old)
>  7c76c5d78b850a9c1adccf8b11ed0164da608f1c (new)
> 
>  I'm using it with meta-freescale - layer to build image to iMX8.
> 
>  I'm using command 'populate_sdk' and it works fine on older version,
>  but newer version it fails with error:
> 
>  Can you provide the steps to reproduce?
> >>> bitbake my-image-name -c populate_sdk
> >>>
>  ==
>  The following packages have unmet dependencies:
>   target-sdk-provides-dummy : Conflicts: coreutils
>  E: Unable to correct problems, you have held broken packages.
> 
> 
>  There is a change sitting in stable/thud-next:
> 
>  http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=stable/thud-next&id=af5cf78b275ab5226354337d25d8dc1c41a08904
> 
>  which might be related. Can you try that branch?
> 
>  git://git.yoctoproject.org/poky-contrib  stable/thud-next
> >>> That did not solve the problem. I have coreutils in my image and it
> >>> kept conflicting. When I removed coreutils from my image it solved
> >>> that problem, but there were some problems with perl etc. From the
> >>> working version all those are missing from
> >>> target-sdk-provices-dummy.bb and my original image works just fine.
> >> I see that thud-branch has gotten even more 'fixes' for this sdk thing
> >> in last week, but the actual problem still stays. If image-recipe uses
> >> coreutils - recipe sdk build fails there because
> >> target-sdk-provides-dummy.bb has it listed. And if I remove that then
> >> it fails on next package.In my case it's bash-dev.
> >>
> >> Does those changes need something different how sdk is build or how to
> >> build sdk with those changes? I'm not sure why they are listed there
> >> in the first place if it overrides the actual package and does not
> >> provide 'dummy' if/when needed.
> >>
> >> To create sdk I use this command: bitbake  -c populate_sdk
> >>
> >> -Teemu
> > I updated to latest thud and this is still an issue. Isn't anyone else
> > building sdk or what I'm doing wrong?
> >
> > I use command: bitbake  -c populate_sdk to generate sdk.
> >
> > With unedited poky - meta layer it stops at error:
> >
> > --
> > The following packages have unmet dependencies:
> >  target-sdk-provides-dummy : Conflicts: coreutils
> > --
> >
> > If I remove that from 
> > poky/meta/recipes-core/meta/target-sdk-provides-dummy.bb
> >
> > The next error is:
> > --
> > The following packages have unmet dependencies:
> >  apt-dev : Depends: apt (= 1.2.24-r0) but it is not going to be installed
> >Recommends: bash-dev
> > --
> >
> > If I remove that from file mentioned before the next error is about
> > perl-dev. If I remove that it ends up on this error:
> >
> > --
> >
> > The following packages have unmet dependencies:
> >  target-sdk-provides-dummy-dev : Depends: target-sdk-provides-dummy (=
> > 1.0-r0) but it is not going to be installed
> > --
> >
> > For testing purposes I removed everything from that file except bash
> > and after that the sdk generated just fine.
> >
> > I don't know enough about yocto/poky so what is the use of this
> > target-sdk-provides-dummy thingie and why things are added there that
> > keep breaking the sdk generation or do I need to generate sdk now
> > someway differently? Atm. I'm either stuck on that older thud -
> > version or I have to manually edit this
> > target-sdk-provides-dummy-dev.bb - file.
>
> Can you log a bug. We are not seeing this in the AutoBuilders.
>
> https://bugzilla.yoctoproject.org/
> >
> > -Teemu
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK build fails at latest thud

2019-05-07 Thread akuster808

Teemu,



On 5/1/19 11:50 PM, Teemu K wrote:
> On Thu, Mar 28, 2019 at 6:36 AM Teemu K  wrote:
>> On Mon, Mar 18, 2019 at 7:21 AM Teemu K  wrote:
>>> On Fri, Mar 15, 2019 at 2:17 AM akuster  wrote:


 On 3/13/19 9:50 PM, Teemu K wrote:

 Hi,

 I noticed that when trying to build sdk on thud it fails on latest
 version. Actually it broke somewhere between commits:

 1cab405d88149fd63322a867c6adb4a80ba68db3 (old)
 7c76c5d78b850a9c1adccf8b11ed0164da608f1c (new)

 I'm using it with meta-freescale - layer to build image to iMX8.

 I'm using command 'populate_sdk' and it works fine on older version,
 but newer version it fails with error:

 Can you provide the steps to reproduce?
>>> bitbake my-image-name -c populate_sdk
>>>
 ==
 The following packages have unmet dependencies:
  target-sdk-provides-dummy : Conflicts: coreutils
 E: Unable to correct problems, you have held broken packages.


 There is a change sitting in stable/thud-next:

 http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=stable/thud-next&id=af5cf78b275ab5226354337d25d8dc1c41a08904

 which might be related. Can you try that branch?

 git://git.yoctoproject.org/poky-contrib  stable/thud-next
>>> That did not solve the problem. I have coreutils in my image and it
>>> kept conflicting. When I removed coreutils from my image it solved
>>> that problem, but there were some problems with perl etc. From the
>>> working version all those are missing from
>>> target-sdk-provices-dummy.bb and my original image works just fine.
>> I see that thud-branch has gotten even more 'fixes' for this sdk thing
>> in last week, but the actual problem still stays. If image-recipe uses
>> coreutils - recipe sdk build fails there because
>> target-sdk-provides-dummy.bb has it listed. And if I remove that then
>> it fails on next package.In my case it's bash-dev.
>>
>> Does those changes need something different how sdk is build or how to
>> build sdk with those changes? I'm not sure why they are listed there
>> in the first place if it overrides the actual package and does not
>> provide 'dummy' if/when needed.
>>
>> To create sdk I use this command: bitbake  -c populate_sdk
>>
>> -Teemu
> I updated to latest thud and this is still an issue. Isn't anyone else
> building sdk or what I'm doing wrong?
>
> I use command: bitbake  -c populate_sdk to generate sdk.
>
> With unedited poky - meta layer it stops at error:
>
> --
> The following packages have unmet dependencies:
>  target-sdk-provides-dummy : Conflicts: coreutils
> --
>
> If I remove that from poky/meta/recipes-core/meta/target-sdk-provides-dummy.bb
>
> The next error is:
> --
> The following packages have unmet dependencies:
>  apt-dev : Depends: apt (= 1.2.24-r0) but it is not going to be installed
>Recommends: bash-dev
> --
>
> If I remove that from file mentioned before the next error is about
> perl-dev. If I remove that it ends up on this error:
>
> --
>
> The following packages have unmet dependencies:
>  target-sdk-provides-dummy-dev : Depends: target-sdk-provides-dummy (=
> 1.0-r0) but it is not going to be installed
> --
>
> For testing purposes I removed everything from that file except bash
> and after that the sdk generated just fine.
>
> I don't know enough about yocto/poky so what is the use of this
> target-sdk-provides-dummy thingie and why things are added there that
> keep breaking the sdk generation or do I need to generate sdk now
> someway differently? Atm. I'm either stuck on that older thud -
> version or I have to manually edit this
> target-sdk-provides-dummy-dev.bb - file.

Can you log a bug. We are not seeing this in the AutoBuilders.

https://bugzilla.yoctoproject.org/
>
> -Teemu

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK build fails at latest thud

2019-05-01 Thread Teemu K

On Thu, Mar 28, 2019 at 6:36 AM Teemu K  wrote:
>
> On Mon, Mar 18, 2019 at 7:21 AM Teemu K  wrote:
> >
> > On Fri, Mar 15, 2019 at 2:17 AM akuster  wrote:
> > >
> > >
> > >
> > > On 3/13/19 9:50 PM, Teemu K wrote:
> > >
> > > Hi,
> > >
> > > I noticed that when trying to build sdk on thud it fails on latest
> > > version. Actually it broke somewhere between commits:
> > >
> > > 1cab405d88149fd63322a867c6adb4a80ba68db3 (old)
> > > 7c76c5d78b850a9c1adccf8b11ed0164da608f1c (new)
> > >
> > > I'm using it with meta-freescale - layer to build image to iMX8.
> > >
> > > I'm using command 'populate_sdk' and it works fine on older version,
> > > but newer version it fails with error:
> > >
> > > Can you provide the steps to reproduce?
> > bitbake my-image-name -c populate_sdk
> >
> > >
> > > ==
> > > The following packages have unmet dependencies:
> > >  target-sdk-provides-dummy : Conflicts: coreutils
> > > E: Unable to correct problems, you have held broken packages.
> > >
> > >
> > > There is a change sitting in stable/thud-next:
> > >
> > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=stable/thud-next&id=af5cf78b275ab5226354337d25d8dc1c41a08904
> > >
> > > which might be related. Can you try that branch?
> > >
> > > git://git.yoctoproject.org/poky-contrib  stable/thud-next
> > That did not solve the problem. I have coreutils in my image and it
> > kept conflicting. When I removed coreutils from my image it solved
> > that problem, but there were some problems with perl etc. From the
> > working version all those are missing from
> > target-sdk-provices-dummy.bb and my original image works just fine.
> I see that thud-branch has gotten even more 'fixes' for this sdk thing
> in last week, but the actual problem still stays. If image-recipe uses
> coreutils - recipe sdk build fails there because
> target-sdk-provides-dummy.bb has it listed. And if I remove that then
> it fails on next package.In my case it's bash-dev.
>
> Does those changes need something different how sdk is build or how to
> build sdk with those changes? I'm not sure why they are listed there
> in the first place if it overrides the actual package and does not
> provide 'dummy' if/when needed.
>
> To create sdk I use this command: bitbake  -c populate_sdk
>
> -Teemu

I updated to latest thud and this is still an issue. Isn't anyone else
building sdk or what I'm doing wrong?

I use command: bitbake  -c populate_sdk to generate sdk.

With unedited poky - meta layer it stops at error:

--
The following packages have unmet dependencies:
 target-sdk-provides-dummy : Conflicts: coreutils
--

If I remove that from poky/meta/recipes-core/meta/target-sdk-provides-dummy.bb

The next error is:
--
The following packages have unmet dependencies:
 apt-dev : Depends: apt (= 1.2.24-r0) but it is not going to be installed
   Recommends: bash-dev
--

If I remove that from file mentioned before the next error is about
perl-dev. If I remove that it ends up on this error:

--

The following packages have unmet dependencies:
 target-sdk-provides-dummy-dev : Depends: target-sdk-provides-dummy (=
1.0-r0) but it is not going to be installed
--

For testing purposes I removed everything from that file except bash
and after that the sdk generated just fine.

I don't know enough about yocto/poky so what is the use of this
target-sdk-provides-dummy thingie and why things are added there that
keep breaking the sdk generation or do I need to generate sdk now
someway differently? Atm. I'm either stuck on that older thud -
version or I have to manually edit this
target-sdk-provides-dummy-dev.bb - file.

-Teemu
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK build fails at latest thud

2019-03-27 Thread Teemu K

On Mon, Mar 18, 2019 at 7:21 AM Teemu K  wrote:
>
> On Fri, Mar 15, 2019 at 2:17 AM akuster  wrote:
> >
> >
> >
> > On 3/13/19 9:50 PM, Teemu K wrote:
> >
> > Hi,
> >
> > I noticed that when trying to build sdk on thud it fails on latest
> > version. Actually it broke somewhere between commits:
> >
> > 1cab405d88149fd63322a867c6adb4a80ba68db3 (old)
> > 7c76c5d78b850a9c1adccf8b11ed0164da608f1c (new)
> >
> > I'm using it with meta-freescale - layer to build image to iMX8.
> >
> > I'm using command 'populate_sdk' and it works fine on older version,
> > but newer version it fails with error:
> >
> > Can you provide the steps to reproduce?
> bitbake my-image-name -c populate_sdk
>
> >
> > ==
> > The following packages have unmet dependencies:
> >  target-sdk-provides-dummy : Conflicts: coreutils
> > E: Unable to correct problems, you have held broken packages.
> >
> >
> > There is a change sitting in stable/thud-next:
> >
> > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=stable/thud-next&id=af5cf78b275ab5226354337d25d8dc1c41a08904
> >
> > which might be related. Can you try that branch?
> >
> > git://git.yoctoproject.org/poky-contrib  stable/thud-next
> That did not solve the problem. I have coreutils in my image and it
> kept conflicting. When I removed coreutils from my image it solved
> that problem, but there were some problems with perl etc. From the
> working version all those are missing from
> target-sdk-provices-dummy.bb and my original image works just fine.
I see that thud-branch has gotten even more 'fixes' for this sdk thing
in last week, but the actual problem still stays. If image-recipe uses
coreutils - recipe sdk build fails there because
target-sdk-provides-dummy.bb has it listed. And if I remove that then
it fails on next package.In my case it's bash-dev.

Does those changes need something different how sdk is build or how to
build sdk with those changes? I'm not sure why they are listed there
in the first place if it overrides the actual package and does not
provide 'dummy' if/when needed.

To create sdk I use this command: bitbake  -c populate_sdk

-Teemu
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK build fails at latest thud

2019-03-17 Thread Teemu K

On Fri, Mar 15, 2019 at 2:17 AM akuster  wrote:
>
>
>
> On 3/13/19 9:50 PM, Teemu K wrote:
>
> Hi,
>
> I noticed that when trying to build sdk on thud it fails on latest
> version. Actually it broke somewhere between commits:
>
> 1cab405d88149fd63322a867c6adb4a80ba68db3 (old)
> 7c76c5d78b850a9c1adccf8b11ed0164da608f1c (new)
>
> I'm using it with meta-freescale - layer to build image to iMX8.
>
> I'm using command 'populate_sdk' and it works fine on older version,
> but newer version it fails with error:
>
> Can you provide the steps to reproduce?
bitbake my-image-name -c populate_sdk

>
> ==
> The following packages have unmet dependencies:
>  target-sdk-provides-dummy : Conflicts: coreutils
> E: Unable to correct problems, you have held broken packages.
>
>
> There is a change sitting in stable/thud-next:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=stable/thud-next&id=af5cf78b275ab5226354337d25d8dc1c41a08904
>
> which might be related. Can you try that branch?
>
> git://git.yoctoproject.org/poky-contrib  stable/thud-next
That did not solve the problem. I have coreutils in my image and it
kept conflicting. When I removed coreutils from my image it solved
that problem, but there were some problems with perl etc. From the
working version all those are missing from
target-sdk-provices-dummy.bb and my original image works just fine.

-Teemu
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK build fails at latest thud

2019-03-14 Thread akuster



On 3/13/19 9:50 PM, Teemu K wrote:
> Hi,
>
> I noticed that when trying to build sdk on thud it fails on latest
> version. Actually it broke somewhere between commits:
>
> 1cab405d88149fd63322a867c6adb4a80ba68db3 (old)
> 7c76c5d78b850a9c1adccf8b11ed0164da608f1c (new)
>
> I'm using it with meta-freescale - layer to build image to iMX8.
>
> I'm using command 'populate_sdk' and it works fine on older version,
> but newer version it fails with error:
Can you provide the steps to reproduce?
>
> ==
> The following packages have unmet dependencies:
>  target-sdk-provides-dummy : Conflicts: coreutils
> E: Unable to correct problems, you have held broken packages.

There is a change sitting in stable/thud-next:

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=stable/thud-next&id=af5cf78b275ab5226354337d25d8dc1c41a08904

which might be related. Can you try that branch?

git://git.yoctoproject.org/poky-contrib  stable/thud-next

- armin
> ==
>
> I'm assuming this is problem in poky - layer and not meta-freescale
> since it can be 'fixed' by downgrading to older version of thud.
>
> -Teemu

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] SDK build fails at latest thud

2019-03-13 Thread Teemu K

Hi,

I noticed that when trying to build sdk on thud it fails on latest
version. Actually it broke somewhere between commits:

1cab405d88149fd63322a867c6adb4a80ba68db3 (old)
7c76c5d78b850a9c1adccf8b11ed0164da608f1c (new)

I'm using it with meta-freescale - layer to build image to iMX8.

I'm using command 'populate_sdk' and it works fine on older version,
but newer version it fails with error:

==
The following packages have unmet dependencies:
 target-sdk-provides-dummy : Conflicts: coreutils
E: Unable to correct problems, you have held broken packages.
==

I'm assuming this is problem in poky - layer and not meta-freescale
since it can be 'fixed' by downgrading to older version of thud.

-Teemu
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK install w/ CMake

2019-02-14 Thread Eric Schwarz

Hi Pascal

I don't think your issue has something do to with CMake.

You are right IMHO. We checked again the pugixml installation behaviour
and it turned out we are experiencing the same issue.

we have got the problem that w/ the Yocto recipe and CMake install
targets

as below always everything (headers and library or binary
respectively) is installed in the SDK.
The binary also goes into the SDK even though we just add it to
IMAGE_INSTALL based on a XILINX yocto build (rel-v2018.3).

I'm not sure I understand what you are trying to do. If you add
something to IMAGE_INSTALL it gets installed to the target.

That usually includes binaries and libraries.

If you only want libraries but not binaries it's probably best to split
them into multiple packages as described in
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#package-splitting-dev-environment

This way you can have the binaries in a different package like
${PN}-tools.

We have not figured out on how to add the build artifacts of the library
to the the correct FILES_${PN} variables. It seems that the FILES_${PN}
variables are also kind of overlayed [1].

a) We would like to see the *.so of the library only on the RootFS but
the headers, the *.so and the *.a in the SDK.
b) We are trying to install a binary via FILES_${PN} but it also ends up
in the SDK no matter what.

A colleague also posted the question on stackoverflow [2] which
describes it more verbosely.

The Yocto release is rocko based.

Thanks
Eric

[1]
https://stackoverflow.com/questions/35090669/bitbake-packaging-strangeness

[2] https://stackoverflow.com/q/54569314/10921299
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK install w/ CMake

2019-02-06 Thread Bach, Pascal

Hi Eric

I don't think your issue has something do to with CMake.

> -Original Message-
> From: yocto-boun...@yoctoproject.org 
> On Behalf Of Eric Schwarz
> Sent: Freitag, 1. Februar 2019 09:51
> To: yocto@yoctoproject.org
> Subject: [yocto] SDK install w/ CMake
> 
> Hello,
> 
> we have got the problem that w/ the Yocto recipe and CMake install targets
> as below always everything (headers and library or binary
> respectively) is installed in the SDK.
> The binary also goes into the SDK even though we just add it to
> IMAGE_INSTALL based on a XILINX yocto build (rel-v2018.3).

I'm not sure I understand what you are trying to do. If you add something to 
IMAGE_INSTALL it gets installed to the target.
That usually includes binaries and libraries.

If you only want libraries but not binaries it's probably best to split them 
into multiple packages as described in 
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#package-splitting-dev-environment

This way you can have the binaries in a different package like ${PN}-tools.

Pascal

> For sure we only want headers to be installed when "-dev"
> is added to TOOLCHAIN_TARGET_TASK_append and the binary should not
> be installed at all when it is just added to IMAGE_INSTALL.
> 
> For sure we studied Yocto and CMake recipes from other libraries where it
> works like pugixml but weren't able to figure out what's going wrong.
> 
> 
> Yocto recipe
> 
> 
> DESCRIPTION = "C++ reflection library"
> SECTION = "libs"
> LICENSE = "CLOSED"
> 
> SRCREV = "${AUTOREV}"
> SRCBRANCH = "next"
> SRC_URI =
> "git://gitlab.company.de/psg/${PN}.git;branch=${SRCBRANCH};protocol=ssh
> "
> 
> DEPENDS = "catch2"
> 
> inherit cmake
> S = "${WORKDIR}/git"
> FILES_${PN}-dev += "${libdir}/cmake"
> 
> # The following are needed because the library is unversioned.
> # See
> https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Librari
> es#Non-versioned_Libraries
> SOLIBS = ".so"
> FILES_SOLIBSDEV = ""
> 
> 
> CMake library install part
> ==
> 
> # Shared client library target.
> add_library(shared SHARED $)
> target_include_directories(shared PUBLIC
>  $
>  $
> )
> 
> set_target_properties(shared
>  PROPERTIES
>  ARCHIVE_OUTPUT_DIRECTORY lib/shared
>  LIBRARY_OUTPUT_DIRECTORY lib/shared
>  RUNTIME_OUTPUT_DIRECTORY lib/shared
>  OUTPUT_NAME ${LIBRARY_NAME}
> )
> 
> # Install target.
> install(TARGETS shared static
>  EXPORT ${LIBRARY_NAME}-config
>  DESTINATION ${CMAKE_INSTALL_LIBDIR})
> install(DIRECTORY include/reflect DESTINATION
> ${CMAKE_INSTALL_INCLUDEDIR})
> install(EXPORT ${LIBRARY_NAME}-config
>  NAMESPACE ${LIBRARY_NAME}-
>  DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/${LIBRARY_NAME})
> 
> 
> CMake binary install part
> =
> 
> install(TARGETS ${EXECUTABLE_NAME} DESTINATION
> ${CMAKE_INSTALL_BINDIR})
> 
> 
> Many thanks for any hints
> Eric
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] SDK install w/ CMake

2019-02-01 Thread Eric Schwarz


Hello,

we have got the problem that w/ the Yocto recipe and CMake install 
targets as below always everything (headers and library or binary 
respectively) is installed in the SDK.
The binary also goes into the SDK even though we just add it to 
IMAGE_INSTALL based on a XILINX yocto build (rel-v2018.3).


For sure we only want headers to be installed when "-dev" 
is added to TOOLCHAIN_TARGET_TASK_append and the binary should not be 
installed at all when it is just added to IMAGE_INSTALL.


For sure we studied Yocto and CMake recipes from other libraries where 
it works like pugixml but weren't able to figure out what's going wrong.



Yocto recipe


DESCRIPTION = "C++ reflection library"
SECTION = "libs"
LICENSE = "CLOSED"

SRCREV = "${AUTOREV}"
SRCBRANCH = "next"
SRC_URI = 
"git://gitlab.company.de/psg/${PN}.git;branch=${SRCBRANCH};protocol=ssh"


DEPENDS = "catch2"

inherit cmake
S = "${WORKDIR}/git"
FILES_${PN}-dev += "${libdir}/cmake"

# The following are needed because the library is unversioned.
# See 
https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries#Non-versioned_Libraries

SOLIBS = ".so"
FILES_SOLIBSDEV = ""


CMake library install part
==

# Shared client library target.
add_library(shared SHARED $)
target_include_directories(shared PUBLIC
$
$
)

set_target_properties(shared
PROPERTIES
ARCHIVE_OUTPUT_DIRECTORY lib/shared
LIBRARY_OUTPUT_DIRECTORY lib/shared
RUNTIME_OUTPUT_DIRECTORY lib/shared
OUTPUT_NAME ${LIBRARY_NAME}
)

# Install target.
install(TARGETS shared static
EXPORT ${LIBRARY_NAME}-config
DESTINATION ${CMAKE_INSTALL_LIBDIR})
install(DIRECTORY include/reflect DESTINATION 
${CMAKE_INSTALL_INCLUDEDIR})

install(EXPORT ${LIBRARY_NAME}-config
NAMESPACE ${LIBRARY_NAME}-
DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/${LIBRARY_NAME})


CMake binary install part
=

install(TARGETS ${EXECUTABLE_NAME} DESTINATION ${CMAKE_INSTALL_BINDIR})


Many thanks for any hints
Eric
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK missing /usr/include/asm header files

2019-01-11 Thread Burton, Ross

meta-toolchain is pretty deprecated now, the preferred method is to run the
populate_sdk task on the image you want a SDK for.

Ross

On Fri, 11 Jan 2019 at 16:21, Grant Edwards 
wrote:

> On Fri, Jan 11, 2019 at 03:52:45PM +, Burton, Ross wrote:
> > On Fri, 11 Jan 2019 at 15:51, Grant Edwards 
> wrote:
> >
> > > I've built a "poky" SDK for use with a Renesas RZN1 eval board (dual
> > > ARM Cortex-A7 cores), and the toolchain's sysroot seems to be missing
> > > the "asm" header directory.
>
> > How did you build the SDK?
>
> Here is the script I used to do the build:
>
> git clone http://git.yoctoproject.org/git/poky
>
> cd poky
> git checkout -b rocko-rzn1 yocto-2.4.3
> git am
> ${RELEASE_DIR}/yocto/rocko/0001-ARM-Add-Cortex-A7-vfpv4-d16*.patch
> cd ..
>
> git clone -b rocko git://git.openembedded.org/meta-openembedded
> git clone https://github.com/cmhe/meta-readonly-rootfs-overlay.git
> git clone -b rocko https://github.com/renesas-rz/meta-rzn1.git
>
> cd poky
> source oe-init-build-env
> cp ${RELDIR}/yocto/bblayers.conf  build/conf/bblayers.conf
> cp ${RELDIR}/yocto/local.conf build/conf/local.conf
> bitbake core-image-minimal
> bitbake meta-toolchain
>
> The core images (kernel, device tree, and rootfs) seem to be OK.
>
> bblayers.conf:
>
> # POKY_BBLAYERS_CONF_VERSION is increased each time
> build/conf/bblayers.conf
> # changes incompatibly
> POKY_BBLAYERS_CONF_VERSION = "2"
>
> BBPATH = "${TOPDIR}"
> BSPPATH := "${@os.path.abspath(os.path.dirname(d.getVar('FILE',True))
> + '/../..')}"
> BBFILES ?= ""
>
> BBLAYERS ?= " \
>   ${BSPPATH}/meta \
>   ${BSPPATH}/meta-poky \
>   ${BSPPATH}/meta-yocto-bsp \
>   ${BSPPATH}/../meta-openembedded/meta-oe \
>   ${BSPPATH}/../meta-openembedded/meta-python \
>   ${BSPPATH}/../meta-openembedded/meta-networking \
>   ${BSPPATH}/../meta-readonly-rootfs-overlay \
>   ${BSPPATH}/../meta-rzn1 \
>"
>
> local.conf:
>
> #
> # This file is your local configuration file and is where all local
> user settings
> # are placed. The comments in this file give some guide to the options
> a new user
> # to the system might want to change but pretty much any configuration
> option can
> # be set in this file. More adventurous users can look at
> local.conf.extended
> # which contains other examples of configuration which can be placed
> in this file
> # but new users likely won't need any of them initially.
> #
> # Lines starting with the '#' character are commented out and in some
> cases the
> # default values are provided as comments to show people example
> syntax. Enabling
> # the option is a question of removing the # character and making any
> change to the
> # variable as required.
>
> #
> # Machine Selection
> #
> # You need to select a specific machine to target the build with.
> There are a selection
> # of emulated machines available which can boot and run in the QEMU
> emulator:
> #
> #MACHINE ?= "qemuarm"
> #MACHINE ?= "qemuarm64"
> #MACHINE ?= "qemumips"
> #MACHINE ?= "qemumips64"
> #MACHINE ?= "qemuppc"
> #MACHINE ?= "qemux86"
> #MACHINE ?= "qemux86-64"
> #
> # There are also the following hardware board target machines included
> for
> # demonstration purposes:
> #
> #MACHINE ?= "beaglebone"
> #MACHINE ?= "genericx86"
> #MACHINE ?= "genericx86-64"
> #MACHINE ?= "mpc8315e-rdb"
> #MACHINE ?= "edgerouter"
> #
> # This sets the default machine to be qemux86 if no other machine is
> selected:
> MACHINE ??= "qemux86"
>
> #
> # Where to place downloads
> #
> # During a first build the system will download many different source
> code tarballs
> # from various upstream projects. This can take a while, particularly
> if your network
> # connection is slow. These are all stored in DL_DIR. When wiping and
> rebuilding you
> # can preserve this directory to speed up this part of subsequent
> builds. This directory
> # is safe to share between multiple builds on the same machine too.
> #
> # The default is a downloads directory under TOPDIR which is the build
> directory.
> #
> DL_DIR ?= "${TOPDIR}/downloads"
>
> #
> # Where to place shared-state files
> #
> # BitBake has the capability to accelerate builds based on previously
> built output.
> # This is done using "shared state" files which can be thought of as
> cache objects
> # and this option determines where those files are placed.
> #
> # You can wipe out TMPDIR leaving this directory intact and the build
> would regenerate
> # from these files if no changes were made to the configuration. If
> changes were made
> # to the configuration, only shared state files where the state was
> still valid would
> # be used (done using checksums).
> #
> # The

Re: [yocto] SDK missing /usr/include/asm header files

2019-01-11 Thread Grant Edwards

On Fri, Jan 11, 2019 at 03:52:45PM +, Burton, Ross wrote:
> On Fri, 11 Jan 2019 at 15:51, Grant Edwards  wrote:
>
> > I've built a "poky" SDK for use with a Renesas RZN1 eval board (dual
> > ARM Cortex-A7 cores), and the toolchain's sysroot seems to be missing
> > the "asm" header directory.

> How did you build the SDK?

Here is the script I used to do the build:

git clone http://git.yoctoproject.org/git/poky

cd poky
git checkout -b rocko-rzn1 yocto-2.4.3
git am ${RELEASE_DIR}/yocto/rocko/0001-ARM-Add-Cortex-A7-vfpv4-d16*.patch
cd ..

git clone -b rocko git://git.openembedded.org/meta-openembedded
git clone https://github.com/cmhe/meta-readonly-rootfs-overlay.git
git clone -b rocko https://github.com/renesas-rz/meta-rzn1.git

cd poky
source oe-init-build-env
cp ${RELDIR}/yocto/bblayers.conf  build/conf/bblayers.conf
cp ${RELDIR}/yocto/local.conf build/conf/local.conf
bitbake core-image-minimal
bitbake meta-toolchain

The core images (kernel, device tree, and rootfs) seem to be OK.

bblayers.conf:

# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BSPPATH := "${@os.path.abspath(os.path.dirname(d.getVar('FILE',True)) + 
'/../..')}"
BBFILES ?= ""

BBLAYERS ?= " \
  ${BSPPATH}/meta \
  ${BSPPATH}/meta-poky \
  ${BSPPATH}/meta-yocto-bsp \
  ${BSPPATH}/../meta-openembedded/meta-oe \
  ${BSPPATH}/../meta-openembedded/meta-python \
  ${BSPPATH}/../meta-openembedded/meta-networking \
  ${BSPPATH}/../meta-readonly-rootfs-overlay \
  ${BSPPATH}/../meta-rzn1 \
   "

local.conf:

#
# This file is your local configuration file and is where all local user 
settings
# are placed. The comments in this file give some guide to the options a 
new user
# to the system might want to change but pretty much any configuration 
option can
# be set in this file. More adventurous users can look at 
local.conf.extended
# which contains other examples of configuration which can be placed in 
this file
# but new users likely won't need any of them initially.
#
# Lines starting with the '#' character are commented out and in some cases 
the
# default values are provided as comments to show people example syntax. 
Enabling
# the option is a question of removing the # character and making any 
change to the
# variable as required.

#
# Machine Selection
#
# You need to select a specific machine to target the build with. There are 
a selection
# of emulated machines available which can boot and run in the QEMU 
emulator:
#
#MACHINE ?= "qemuarm"
#MACHINE ?= "qemuarm64"
#MACHINE ?= "qemumips"
#MACHINE ?= "qemumips64"
#MACHINE ?= "qemuppc"
#MACHINE ?= "qemux86"
#MACHINE ?= "qemux86-64"
#
# There are also the following hardware board target machines included for 
# demonstration purposes:
#
#MACHINE ?= "beaglebone"
#MACHINE ?= "genericx86"
#MACHINE ?= "genericx86-64"
#MACHINE ?= "mpc8315e-rdb"
#MACHINE ?= "edgerouter"
#
# This sets the default machine to be qemux86 if no other machine is 
selected:
MACHINE ??= "qemux86"

#
# Where to place downloads
#
# During a first build the system will download many different source code 
tarballs
# from various upstream projects. This can take a while, particularly if 
your network
# connection is slow. These are all stored in DL_DIR. When wiping and 
rebuilding you
# can preserve this directory to speed up this part of subsequent builds. 
This directory
# is safe to share between multiple builds on the same machine too.
#
# The default is a downloads directory under TOPDIR which is the build 
directory.
#
DL_DIR ?= "${TOPDIR}/downloads"

#
# Where to place shared-state files
#
# BitBake has the capability to accelerate builds based on previously built 
output.
# This is done using "shared state" files which can be thought of as cache 
objects
# and this option determines where those files are placed.
#
# You can wipe out TMPDIR leaving this directory intact and the build would 
regenerate
# from these files if no changes were made to the configuration. If changes 
were made
# to the configuration, only shared state files where the state was still 
valid would
# be used (done using checksums).
#
# The default is a sstate-cache directory under TOPDIR.
#
#SSTATE_DIR ?= "${TOPDIR}/sstate-cache"

#
# Where to place the build output
#
# This option specifies where the bulk of the building work should be done 
and
# where BitBake should place its temporary files and output. Keep in mind 
that
# this includes the extraction and compilation of many applications and the 
toolch

Re: [yocto] SDK missing /usr/include/asm header files

2019-01-11 Thread Burton, Ross

How did you build the SDK?

Ross

On Fri, 11 Jan 2019 at 15:51, Grant Edwards 
wrote:

>
> I've built a "poky" SDK for use with a Renesas RZN1 eval board (dual
> ARM Cortex-A7 cores), and the toolchain's sysroot seems to be missing
> the "asm" header directory.  When I try to compile a simple tcp echo
> server program I get this:
>
>
> /home/grante/rzn1d/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc
> --sysroot=/home/grante/rzn1d/toolchain/sysroots/armv7vehf-vfp-poky-linux-gnueabi
> -march=armv7ve -marm -mfpu=vfp -mfloat-abi=hard -Wall -Werror -std=gnu99 -c
> tcpecho.c
> In file included from
> /home/grante/rzn1d/toolchain/sysroots/armv7vehf-vfp-poky-linux-gnueabi/usr/include/signal.h:287:0,
>  from
> /home/grante/rzn1d/toolchain/sysroots/armv7vehf-vfp-poky-linux-gnueabi/usr/include/sys/wait.h:36,
>  from tcpecho.c:6:
>
> /home/grante/rzn1d/toolchain/sysroots/armv7vehf-vfp-poky-linux-gnueabi/usr/include/bits/sigcontext.h:30:11:
> fatal error: asm/sigcontext.h: No such file or directory
>  # include 
>^~
> compilation terminated.
> make: *** [Makefile:26: tcpecho.o] Error 1
>
> Browsing throught the installed toolchain's sysroot confirms that gcc
> is correct: there's no "asm" directory in the sysroot's usr/include
> directory (or anywhere else in the toolchain's installation tree).
>
> This is the first time I've tried to build an SDK, so I've probably
> done something wrong, but I could use a clue as to what might have
> gone wrong...
>
> --
> Grant Edwards   grant.b.edwardsYow! What's the MATTER
>   at   Sid? ... Is your
> BEVERAGE
>   gmail.comunsatisfactory?
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] SDK missing /usr/include/asm header files

2019-01-11 Thread Grant Edwards



I've built a "poky" SDK for use with a Renesas RZN1 eval board (dual
ARM Cortex-A7 cores), and the toolchain's sysroot seems to be missing
the "asm" header directory.  When I try to compile a simple tcp echo
server program I get this:


/home/grante/rzn1d/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc
 
--sysroot=/home/grante/rzn1d/toolchain/sysroots/armv7vehf-vfp-poky-linux-gnueabi
 -march=armv7ve -marm -mfpu=vfp -mfloat-abi=hard -Wall -Werror -std=gnu99 -c 
tcpecho.c
In file included from 
/home/grante/rzn1d/toolchain/sysroots/armv7vehf-vfp-poky-linux-gnueabi/usr/include/signal.h:287:0,
 from 
/home/grante/rzn1d/toolchain/sysroots/armv7vehf-vfp-poky-linux-gnueabi/usr/include/sys/wait.h:36,
 from tcpecho.c:6:

/home/grante/rzn1d/toolchain/sysroots/armv7vehf-vfp-poky-linux-gnueabi/usr/include/bits/sigcontext.h:30:11:
 fatal error: asm/sigcontext.h: No such file or directory
 # include 
   ^~
compilation terminated.
make: *** [Makefile:26: tcpecho.o] Error 1

Browsing throught the installed toolchain's sysroot confirms that gcc
is correct: there's no "asm" directory in the sysroot's usr/include
directory (or anywhere else in the toolchain's installation tree).

This is the first time I've tried to build an SDK, so I've probably
done something wrong, but I could use a clue as to what might have
gone wrong...

-- 
Grant Edwards   grant.b.edwardsYow! What's the MATTER
  at   Sid? ... Is your BEVERAGE
  gmail.comunsatisfactory?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [SDK] including kernel devsrc to the SDK failes

2018-10-29 Thread Bruce Ashfield

On 2018-10-29 11:18 AM, Bas Mevissen wrote:

On 2018-10-29 16:14, Bruce Ashfield wrote:

On 2018-10-29 11:12 AM, Khem Raj wrote:

On Mon, Oct 29, 2018 at 6:46 AM Bruce Ashfield
wrote:

On 10/29/2018 9:10 AM, Khem Raj wrote:

On Fri, Oct 26, 2018 at 6:54 AM Bruce Ashfield
wrote:

On 10/26/2018 4:28 AM, Måns Zigher wrote:
So it looks like the number of /bin/awk have increased so the
patch will
fix one problem but there is more to fix. I have a "workaround"
evenYup. That works too (as would a variable from the env), but
we'll still

need a sed based patch in the short term.
though I am not so sure it is a workaround or not. The problem is
fixed

adding to kernel-devsrc.bbappend

do_install_append() {
# This fixes the rpm dependency failure on install of kernel-devsrc
depending on /bin/awk
cd ${D} || true
for i in $(grep -srI "!/bin/awk" | cut -d":" -f1); do
sed -i -e "s#!/bin/awk#!/usr/bin/env awk#g" $i
done
}

The original solution can be found at

https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=blobdiff;f=meta-agl-bsp/meta-ti/recipes-kernel/linux/linux-ti-staging_%25.bbappend;h=43fa494a26c132b875c177acf0389163d5e34c06;hp=b2e5431400acef0a5372e5490ac4f464482d4b3b;hb=4bfc821810cdee47611c6d3e94d771971f51fa75;hpb=1cf6b17fd15fde569374c85d4df722784f4e9c67

The best solution might be to add kernel patches but since the
number of
/bin/awk have increased I think that this is fine in the kernel
universe
but a problem in poky universe. So by adding it to kernel-devsrc
it will
make sure that when the kernel get's tainted in the future it
will not
break the rpm build. This is a "bug" only when using rpm ipk will
not

detect it as a problem.

I'm ok with this type of solution as well, since this is similar
to what we've had to do with perf in the past (sed and modify versus
patching). I can always patch and fix things in linux-yocto, but then
another other kernel still suffers the issue.

can we fix it in upstream kernel to use something like
#!/usr/bin/env awk
may be ?

Yup. That works too (as would a variable from the env), but we'll still
need a sed based patch in the short term.

short term is fine, but I think this should be fixed in upstream kernel.

Also agreed. That was my primary suggestion as well, since even with
that slow pace, we'd have it in all the kernel trees by the next
Yocto release window.

I would recommend to keep some kind of automated hot patching in as not
all vendor kernels will catch up that quickly, if ever.

That is what we normally do. See the old perf patches. They test for
the issue, and then sed the change if required.

Bruce

-- Bas.

Bruce

It would be better if folks with this problem also send patches
upstream
to allow us to vary the location of awk via a variable, since that
would
eventually fix all kernels without needing any modifications ..
but that

is a medium term time play, versus doing the sed operation.

If you have a patch to kernel-devsrc in master, feel free to send it
and cc' me, and I can pull it into my queue, test and then send it in
my next pull request.

Bruce

BR
Måns Zigher

Den tors 25 okt. 2018 kl 13:19 skrev Måns Zigher

Hi,

I am trying to add the kernel devsrc to the SDK but I am
getting the

following error

Problem: conflicting requests
- nothing provides /bin/awk needed by
kernel-devsrc-1.0-r0.imx8mqevk

I have applied the following patch to try and fix this
problem.

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?id=8af11c1cdd8fa08217e702b57cf96e9030db52b2

running the task do_populate_sdk. Any suggestion on how to get
forward on this error. I would like to run dnf manually to
check any
dependency of the kernel-devsrc rpm package but cannot
figure out how.

BR
Måns Zigher

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [SDK] including kernel devsrc to the SDK failes

2018-10-29 Thread Bas Mevissen

On 2018-10-29 16:14, Bruce Ashfield wrote:

On 2018-10-29 11:12 AM, Khem Raj wrote:

On Mon, Oct 29, 2018 at 6:46 AM Bruce Ashfield
wrote:

On 10/29/2018 9:10 AM, Khem Raj wrote:

On Fri, Oct 26, 2018 at 6:54 AM Bruce Ashfield
wrote:

need a sed based patch in the short term.
though I am not so sure it is a workaround or not. The problem is
fixed

adding to kernel-devsrc.bbappend

do_install_append() {
# This fixes the rpm dependency failure on install of
kernel-devsrc

depending on /bin/awk
cd ${D} || true
for i in $(grep -srI "!/bin/awk" | cut -d":" -f1); do
sed -i -e "s#!/bin/awk#!/usr/bin/env awk#g" $i
done
}

The original solution can be found at

The best solution might be to add kernel patches but since the
number of
/bin/awk have increased I think that this is fine in the kernel
universe
but a problem in poky universe. So by adding it to kernel-devsrc
it will
make sure that when the kernel get's tainted in the future it will
not
break the rpm build. This is a "bug" only when using rpm ipk will
not

detect it as a problem.

I'm ok with this type of solution as well, since this is similar
to what we've had to do with perf in the past (sed and modify
versus
patching). I can always patch and fix things in linux-yocto, but
then

another other kernel still suffers the issue.

can we fix it in upstream kernel to use something like
#!/usr/bin/env awk
may be ?

Yup. That works too (as would a variable from the env), but we'll
still

need a sed based patch in the short term.

short term is fine, but I think this should be fixed in upstream
kernel.

Also agreed. That was my primary suggestion as well, since even with
that slow pace, we'd have it in all the kernel trees by the next
Yocto release window.

I would recommend to keep some kind of automated hot patching in as not
all vendor kernels will catch up that quickly, if ever.

-- Bas.

Bruce

is a medium term time play, versus doing the sed operation.

If you have a patch to kernel-devsrc in master, feel free to send
it
and cc' me, and I can pull it into my queue, test and then send it
in

my next pull request.

Bruce

BR
Måns Zigher

Den tors 25 okt. 2018 kl 13:19 skrev Måns Zigher

Hi,

I am trying to add the kernel devsrc to the SDK but I am
getting the

following error

Problem: conflicting requests
- nothing provides /bin/awk needed by
kernel-devsrc-1.0-r0.imx8mqevk

I have applied the following patch to try and fix this
problem.

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?id=8af11c1cdd8fa08217e702b57cf96e9030db52b2

I have verified that it was applied and run kernel-devsrc
works. The
error is from do_populate_sdk and I am suspecting that the
problem
is related to me using rpm. I believe rpm might be to smart
in this
case detecting the dependency and resulting dnf from failing
when
running the task do_populate_sdk. Any suggestion on how to
get
forward on this error. I would like to run dnf manually to
check any
dependency of the kernel-devsrc rpm package but cannot
figure out how.

BR
Måns Zigher

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [SDK] including kernel devsrc to the SDK failes

2018-10-29 Thread Khem Raj

On Mon, Oct 29, 2018 at 8:14 AM Bruce Ashfield
 wrote:
>
> On 2018-10-29 11:12 AM, Khem Raj wrote:
> > On Mon, Oct 29, 2018 at 6:46 AM Bruce Ashfield
> >  wrote:
> >>
> >>
> >>
> >> On 10/29/2018 9:10 AM, Khem Raj wrote:
> >>> On Fri, Oct 26, 2018 at 6:54 AM Bruce Ashfield
> >>>  wrote:
> 
> 
> 
>  On 10/26/2018 4:28 AM, Måns Zigher wrote:
> > So it looks like the number of /bin/awk have increased so the patch will
> > fix one problem but there is more to fix. I have a "workaround" 
> > evenYup. That works too (as would a variable from the env), but we'll 
> > still
> > need a sed based patch in the short term.
> > though I am not so sure it is a workaround or not. The problem is fixed
> > adding to kernel-devsrc.bbappend
> >
> > do_install_append() {
> > # This fixes the rpm dependency failure on install of kernel-devsrc
> > depending on /bin/awk
> > cd ${D} || true
> > for i in $(grep -srI "!/bin/awk" | cut -d":" -f1); do
> > sed -i -e "s#!/bin/awk#!/usr/bin/env awk#g" $i
> > done
> > }
> >
> > The original solution can be found at
> >
> > https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=blobdiff;f=meta-agl-bsp/meta-ti/recipes-kernel/linux/linux-ti-staging_%25.bbappend;h=43fa494a26c132b875c177acf0389163d5e34c06;hp=b2e5431400acef0a5372e5490ac4f464482d4b3b;hb=4bfc821810cdee47611c6d3e94d771971f51fa75;hpb=1cf6b17fd15fde569374c85d4df722784f4e9c67
> >
> > The best solution might be to add kernel patches but since the number of
> > /bin/awk have increased I think that this is fine in the kernel universe
> > but a problem in poky universe. So by adding it to kernel-devsrc it will
> > make sure that when the kernel get's tainted in the future it will not
> > break the rpm build. This is a "bug" only when using rpm ipk will not
> > detect it as a problem.
> 
>  I'm ok with this type of solution as well, since this is similar
>  to what we've had to do with perf in the past (sed and modify versus
>  patching). I can always patch and fix things in linux-yocto, but then
>  another other kernel still suffers the issue.
> >>>
> >>>
> >>> can we fix it in upstream kernel to use something like
> >>> #!/usr/bin/env awk
> >>> may be ?
> >>
> >>
> >> Yup. That works too (as would a variable from the env), but we'll still
> >> need a sed based patch in the short term.
> >>
> >
> > short term is fine, but I think this should be fixed in upstream kernel.
>
> Also agreed. That was my primary suggestion as well, since even with
> that slow pace, we'd have it in all the kernel trees by the next
> Yocto release window.

thats reasonable
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [SDK] including kernel devsrc to the SDK failes

2018-10-29 Thread Bruce Ashfield

On 2018-10-29 11:12 AM, Khem Raj wrote:

On Mon, Oct 29, 2018 at 6:46 AM Bruce Ashfield
wrote:

On 10/29/2018 9:10 AM, Khem Raj wrote:

On Fri, Oct 26, 2018 at 6:54 AM Bruce Ashfield
wrote:

On 10/26/2018 4:28 AM, Måns Zigher wrote:

So it looks like the number of /bin/awk have increased so the patch will
fix one problem but there is more to fix. I have a "workaround" evenYup. That
works too (as would a variable from the env), but we'll still

need a sed based patch in the short term.

though I am not so sure it is a workaround or not. The problem is fixed
adding to kernel-devsrc.bbappend

The original solution can be found at

The best solution might be to add kernel patches but since the number of
/bin/awk have increased I think that this is fine in the kernel universe
but a problem in poky universe. So by adding it to kernel-devsrc it will
make sure that when the kernel get's tainted in the future it will not
break the rpm build. This is a "bug" only when using rpm ipk will not
detect it as a problem.

can we fix it in upstream kernel to use something like
#!/usr/bin/env awk
may be ?

Yup. That works too (as would a variable from the env), but we'll still
need a sed based patch in the short term.

short term is fine, but I think this should be fixed in upstream kernel.

Also agreed. That was my primary suggestion as well, since even with
that slow pace, we'd have it in all the kernel trees by the next
Yocto release window.

Bruce

It would be better if folks with this problem also send patches upstream
to allow us to vary the location of awk via a variable, since that would
eventually fix all kernels without needing any modifications .. but that
is a medium term time play, versus doing the sed operation.

If you have a patch to kernel-devsrc in master, feel free to send it
and cc' me, and I can pull it into my queue, test and then send it in
my next pull request.

Bruce

BR
Måns Zigher

Den tors 25 okt. 2018 kl 13:19 skrev Måns Zigher mailto:mans.zig...@gmail.com>>:

Hi,

I am trying to add the kernel devsrc to the SDK but I am getting the
following error

Problem: conflicting requests
- nothing provides /bin/awk needed by kernel-devsrc-1.0-r0.imx8mqevk

I have applied the following patch to try and fix this problem.

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?id=8af11c1cdd8fa08217e702b57cf96e9030db52b2

I have verified that it was applied and run kernel-devsrc works. The
error is from do_populate_sdk and I am suspecting that the problem
is related to me using rpm. I believe rpm might be to smart in this
case detecting the dependency and resulting dnf from failing when
running the task do_populate_sdk. Any suggestion on how to get
forward on this error. I would like to run dnf manually to check any
dependency of the kernel-devsrc rpm package but cannot figure out how.

BR
Måns Zigher

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [SDK] including kernel devsrc to the SDK failes

2018-10-29 Thread Khem Raj

On Mon, Oct 29, 2018 at 6:46 AM Bruce Ashfield
 wrote:
>
>
>
> On 10/29/2018 9:10 AM, Khem Raj wrote:
> > On Fri, Oct 26, 2018 at 6:54 AM Bruce Ashfield
> >  wrote:
> >>
> >>
> >>
> >> On 10/26/2018 4:28 AM, Måns Zigher wrote:
> >>> So it looks like the number of /bin/awk have increased so the patch will
> >>> fix one problem but there is more to fix. I have a "workaround" evenYup. 
> >>> That works too (as would a variable from the env), but we'll still
need a sed based patch in the short term.
> >>> though I am not so sure it is a workaround or not. The problem is fixed
> >>> adding to kernel-devsrc.bbappend
> >>>
> >>> do_install_append() {
> >>> # This fixes the rpm dependency failure on install of kernel-devsrc
> >>> depending on /bin/awk
> >>> cd ${D} || true
> >>> for i in $(grep -srI "!/bin/awk" | cut -d":" -f1); do
> >>> sed -i -e "s#!/bin/awk#!/usr/bin/env awk#g" $i
> >>> done
> >>> }
> >>>
> >>> The original solution can be found at
> >>>
> >>> https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=blobdiff;f=meta-agl-bsp/meta-ti/recipes-kernel/linux/linux-ti-staging_%25.bbappend;h=43fa494a26c132b875c177acf0389163d5e34c06;hp=b2e5431400acef0a5372e5490ac4f464482d4b3b;hb=4bfc821810cdee47611c6d3e94d771971f51fa75;hpb=1cf6b17fd15fde569374c85d4df722784f4e9c67
> >>>
> >>> The best solution might be to add kernel patches but since the number of
> >>> /bin/awk have increased I think that this is fine in the kernel universe
> >>> but a problem in poky universe. So by adding it to kernel-devsrc it will
> >>> make sure that when the kernel get's tainted in the future it will not
> >>> break the rpm build. This is a "bug" only when using rpm ipk will not
> >>> detect it as a problem.
> >>
> >> I'm ok with this type of solution as well, since this is similar
> >> to what we've had to do with perf in the past (sed and modify versus
> >> patching). I can always patch and fix things in linux-yocto, but then
> >> another other kernel still suffers the issue.
> >
> >
> > can we fix it in upstream kernel to use something like
> > #!/usr/bin/env awk
> > may be ?
>
>
> Yup. That works too (as would a variable from the env), but we'll still
> need a sed based patch in the short term.
>

short term is fine, but I think this should be fixed in upstream kernel.

> Bruce
>
> >
> >>
> >> It would be better if folks with this problem also send patches upstream
> >> to allow us to vary the location of awk via a variable, since that would
> >> eventually fix all kernels without needing any modifications .. but that
> >> is a medium term time play, versus doing the sed operation.
> >>
> >> If you have a patch to kernel-devsrc in master, feel free to send it
> >> and cc' me, and I can pull it into my queue, test and then send it in
> >> my next pull request.
> >>
> >> Bruce
> >>
> >>>
> >>> BR
> >>> Måns Zigher
> >>>
> >>> Den tors 25 okt. 2018 kl 13:19 skrev Måns Zigher  >>> >:
> >>>
> >>>  Hi,
> >>>
> >>>  I am trying to add the kernel devsrc to the SDK but I am getting the
> >>>  following error
> >>>
> >>>  Problem: conflicting requests
> >>> - nothing provides /bin/awk needed by 
> >>> kernel-devsrc-1.0-r0.imx8mqevk
> >>>
> >>>  I have applied the following patch to try and fix this problem.
> >>>
> >>>  
> >>> http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?id=8af11c1cdd8fa08217e702b57cf96e9030db52b2
> >>>
> >>>  I have verified that it was applied and run kernel-devsrc works. The
> >>>  error is from do_populate_sdk and I am suspecting that the problem
> >>>  is related to me using rpm. I believe rpm might be to smart in this
> >>>  case detecting the dependency and resulting dnf from failing when
> >>>  running the task do_populate_sdk. Any suggestion on how to get
> >>>  forward on this error. I would like to run dnf manually to check any
> >>>  dependency of the kernel-devsrc rpm package but cannot figure out 
> >>> how.
> >>>
> >>>  BR
> >>>  Måns Zigher
> >>>
> >>>
> >>>
> >> --
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [SDK] including kernel devsrc to the SDK failes

2018-10-29 Thread Bruce Ashfield

On 10/29/2018 9:10 AM, Khem Raj wrote:

On Fri, Oct 26, 2018 at 6:54 AM Bruce Ashfield
wrote:

On 10/26/2018 4:28 AM, Måns Zigher wrote:

So it looks like the number of /bin/awk have increased so the patch will
fix one problem but there is more to fix. I have a "workaround" even
though I am not so sure it is a workaround or not. The problem is fixed
adding to kernel-devsrc.bbappend

The original solution can be found at

The best solution might be to add kernel patches but since the number of
/bin/awk have increased I think that this is fine in the kernel universe
but a problem in poky universe. So by adding it to kernel-devsrc it will
make sure that when the kernel get's tainted in the future it will not
break the rpm build. This is a "bug" only when using rpm ipk will not
detect it as a problem.

can we fix it in upstream kernel to use something like
#!/usr/bin/env awk
may be ?

Yup. That works too (as would a variable from the env), but we'll still
need a sed based patch in the short term.

Bruce

It would be better if folks with this problem also send patches upstream
to allow us to vary the location of awk via a variable, since that would
eventually fix all kernels without needing any modifications .. but that
is a medium term time play, versus doing the sed operation.

If you have a patch to kernel-devsrc in master, feel free to send it
and cc' me, and I can pull it into my queue, test and then send it in
my next pull request.

Bruce

BR
Måns Zigher

Den tors 25 okt. 2018 kl 13:19 skrev Måns Zigher mailto:mans.zig...@gmail.com>>:

Hi,

I am trying to add the kernel devsrc to the SDK but I am getting the
following error

Problem: conflicting requests
- nothing provides /bin/awk needed by kernel-devsrc-1.0-r0.imx8mqevk

I have applied the following patch to try and fix this problem.

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?id=8af11c1cdd8fa08217e702b57cf96e9030db52b2

I have verified that it was applied and run kernel-devsrc works. The
error is from do_populate_sdk and I am suspecting that the problem
is related to me using rpm. I believe rpm might be to smart in this
case detecting the dependency and resulting dnf from failing when
running the task do_populate_sdk. Any suggestion on how to get
forward on this error. I would like to run dnf manually to check any
dependency of the kernel-devsrc rpm package but cannot figure out how.

BR
Måns Zigher

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [SDK] including kernel devsrc to the SDK failes

2018-10-29 Thread Khem Raj

On Fri, Oct 26, 2018 at 6:54 AM Bruce Ashfield
 wrote:
>
>
>
> On 10/26/2018 4:28 AM, Måns Zigher wrote:
> > So it looks like the number of /bin/awk have increased so the patch will
> > fix one problem but there is more to fix. I have a "workaround" even
> > though I am not so sure it is a workaround or not. The problem is fixed
> > adding to kernel-devsrc.bbappend
> >
> > do_install_append() {
> > # This fixes the rpm dependency failure on install of kernel-devsrc
> > depending on /bin/awk
> > cd ${D} || true
> > for i in $(grep -srI "!/bin/awk" | cut -d":" -f1); do
> > sed -i -e "s#!/bin/awk#!/usr/bin/env awk#g" $i
> > done
> > }
> >
> > The original solution can be found at
> >
> > https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=blobdiff;f=meta-agl-bsp/meta-ti/recipes-kernel/linux/linux-ti-staging_%25.bbappend;h=43fa494a26c132b875c177acf0389163d5e34c06;hp=b2e5431400acef0a5372e5490ac4f464482d4b3b;hb=4bfc821810cdee47611c6d3e94d771971f51fa75;hpb=1cf6b17fd15fde569374c85d4df722784f4e9c67
> >
> > The best solution might be to add kernel patches but since the number of
> > /bin/awk have increased I think that this is fine in the kernel universe
> > but a problem in poky universe. So by adding it to kernel-devsrc it will
> > make sure that when the kernel get's tainted in the future it will not
> > break the rpm build. This is a "bug" only when using rpm ipk will not
> > detect it as a problem.
>
> I'm ok with this type of solution as well, since this is similar
> to what we've had to do with perf in the past (sed and modify versus
> patching). I can always patch and fix things in linux-yocto, but then
> another other kernel still suffers the issue.


can we fix it in upstream kernel to use something like
#!/usr/bin/env awk
may be ?

>
> It would be better if folks with this problem also send patches upstream
> to allow us to vary the location of awk via a variable, since that would
> eventually fix all kernels without needing any modifications .. but that
> is a medium term time play, versus doing the sed operation.
>
> If you have a patch to kernel-devsrc in master, feel free to send it
> and cc' me, and I can pull it into my queue, test and then send it in
> my next pull request.
>
> Bruce
>
> >
> > BR
> > Måns Zigher
> >
> > Den tors 25 okt. 2018 kl 13:19 skrev Måns Zigher  > >:
> >
> > Hi,
> >
> > I am trying to add the kernel devsrc to the SDK but I am getting the
> > following error
> >
> > Problem: conflicting requests
> >- nothing provides /bin/awk needed by kernel-devsrc-1.0-r0.imx8mqevk
> >
> > I have applied the following patch to try and fix this problem.
> >
> > 
> > http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?id=8af11c1cdd8fa08217e702b57cf96e9030db52b2
> >
> > I have verified that it was applied and run kernel-devsrc works. The
> > error is from do_populate_sdk and I am suspecting that the problem
> > is related to me using rpm. I believe rpm might be to smart in this
> > case detecting the dependency and resulting dnf from failing when
> > running the task do_populate_sdk. Any suggestion on how to get
> > forward on this error. I would like to run dnf manually to check any
> > dependency of the kernel-devsrc rpm package but cannot figure out how.
> >
> > BR
> > Måns Zigher
> >
> >
> >
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [SDK] including kernel devsrc to the SDK failes

2018-10-26 Thread Bruce Ashfield

On 10/26/2018 4:28 AM, Måns Zigher wrote:
So it looks like the number of /bin/awk have increased so the patch will
fix one problem but there is more to fix. I have a "workaround" even
though I am not so sure it is a workaround or not. The problem is fixed
adding to kernel-devsrc.bbappend

do_install_append() {
# This fixes the rpm dependency failure on install of kernel-devsrc
depending on /bin/awk

cd ${D} || true
for i in $(grep -srI "!/bin/awk" | cut -d":" -f1); do
sed -i -e "s#!/bin/awk#!/usr/bin/env awk#g" $i
done
}

The original solution can be found at

The best solution might be to add kernel patches but since the number of
/bin/awk have increased I think that this is fine in the kernel universe
but a problem in poky universe. So by adding it to kernel-devsrc it will
make sure that when the kernel get's tainted in the future it will not
break the rpm build. This is a "bug" only when using rpm ipk will not
detect it as a problem.

It would be better if folks with this problem also send patches upstream
to allow us to vary the location of awk via a variable, since that would
eventually fix all kernels without needing any modifications .. but that
is a medium term time play, versus doing the sed operation.

If you have a patch to kernel-devsrc in master, feel free to send it
and cc' me, and I can pull it into my queue, test and then send it in
my next pull request.

Bruce

BR
Måns Zigher

Den tors 25 okt. 2018 kl 13:19 skrev Måns Zigher >:

Hi,

I am trying to add the kernel devsrc to the SDK but I am getting the
following error

Problem: conflicting requests
- nothing provides /bin/awk needed by kernel-devsrc-1.0-r0.imx8mqevk

I have applied the following patch to try and fix this problem.

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?id=8af11c1cdd8fa08217e702b57cf96e9030db52b2

I have verified that it was applied and run kernel-devsrc works. The
error is from do_populate_sdk and I am suspecting that the problem
is related to me using rpm. I believe rpm might be to smart in this
case detecting the dependency and resulting dnf from failing when
running the task do_populate_sdk. Any suggestion on how to get
forward on this error. I would like to run dnf manually to check any
dependency of the kernel-devsrc rpm package but cannot figure out how.

BR
Måns Zigher

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [SDK] including kernel devsrc to the SDK failes

2018-10-26 Thread Måns Zigher

So it looks like the number of /bin/awk have increased so the patch will
fix one problem but there is more to fix. I have a "workaround" even though
I am not so sure it is a workaround or not. The problem is fixed adding to
kernel-devsrc.bbappend

do_install_append() {
# This fixes the rpm dependency failure on install of kernel-devsrc
depending on /bin/awk
cd ${D} || true
for i in $(grep -srI "!/bin/awk" | cut -d":" -f1); do
sed -i -e "s#!/bin/awk#!/usr/bin/env awk#g" $i
done
}

The original solution can be found at

https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=blobdiff;f=meta-agl-bsp/meta-ti/recipes-kernel/linux/linux-ti-staging_%25.bbappend;h=43fa494a26c132b875c177acf0389163d5e34c06;hp=b2e5431400acef0a5372e5490ac4f464482d4b3b;hb=4bfc821810cdee47611c6d3e94d771971f51fa75;hpb=1cf6b17fd15fde569374c85d4df722784f4e9c67

The best solution might be to add kernel patches but since the number of
/bin/awk have increased I think that this is fine in the kernel universe
but a problem in poky universe. So by adding it to kernel-devsrc it will
make sure that when the kernel get's tainted in the future it will not
break the rpm build. This is a "bug" only when using rpm ipk will not
detect it as a problem.

BR
Måns Zigher

Den tors 25 okt. 2018 kl 13:19 skrev Måns Zigher :

> Hi,
>
> I am trying to add the kernel devsrc to the SDK but I am getting the
> following error
>
> Problem: conflicting requests
>   - nothing provides /bin/awk needed by kernel-devsrc-1.0-r0.imx8mqevk
>
> I have applied the following patch to try and fix this problem.
>
>
> http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?id=8af11c1cdd8fa08217e702b57cf96e9030db52b2
>
> I have verified that it was applied and run kernel-devsrc works. The error
> is from do_populate_sdk and I am suspecting that the problem is related to
> me using rpm. I believe rpm might be to smart in this case detecting the
> dependency and resulting dnf from failing when running the task
> do_populate_sdk. Any suggestion on how to get forward on this error. I
> would like to run dnf manually to check any dependency of the kernel-devsrc
> rpm package but cannot figure out how.
>
> BR
> Måns Zigher
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [SDK] including kernel devsrc to the SDK failes

2018-10-25 Thread Måns Zigher

Hi,

I am trying to add the kernel devsrc to the SDK but I am getting the
following error

Problem: conflicting requests
  - nothing provides /bin/awk needed by kernel-devsrc-1.0-r0.imx8mqevk

I have applied the following patch to try and fix this problem.

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?id=8af11c1cdd8fa08217e702b57cf96e9030db52b2

I have verified that it was applied and run kernel-devsrc works. The error
is from do_populate_sdk and I am suspecting that the problem is related to
me using rpm. I believe rpm might be to smart in this case detecting the
dependency and resulting dnf from failing when running the task
do_populate_sdk. Any suggestion on how to get forward on this error. I
would like to run dnf manually to check any dependency of the kernel-devsrc
rpm package but cannot figure out how.

BR
Måns Zigher
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto SDK generated - unable to compile application

2018-09-21 Thread Bas Mevissen

On 2018-09-21 14:34, Evan O'Loughlin wrote:

From: Bas Mevissen [ab...@basmevissen.nl]
Sent: 20 September 2018 23:21
To: Evan O'Loughlin
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto SDK generated - unable to compile 
application

On 9/20/18 3:32 PM, Evan O'Loughlin wrote:

From: Bas Mevissen [ab...@basmevissen.nl]
Sent: 20 September 2018 13:23
To: Evan O'Loughlin
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto SDK generated - unable to compile 
application

On 2018-09-20 12:28, Evan O'Loughlin wrote:

From: Bas Mevissen [ab...@basmevissen.nl]
Sent: 20 September 2018 10:50
To: Evan O'Loughlin
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto SDK generated - unable to compile
application

On 2018-09-20 11:40, Evan O'Loughlin wrote:

-Original Message-
From: Bas Mevissen [mailto:ab...@basmevissen.nl]
Sent: 20 September 2018 10:12
To: Evan O'Loughlin 
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto SDK generated - unable to compile
application

On 2018-09-20 10:08, Evan O'Loughlin wrote:

Hello,

I’m having an issue when I try to use the SDK generated by my yocto
instance.
Currently I have yocto set-up to correctly build my image – this 
all

works well.

I've built the SDK in the following ways:
   * bitbake {image} –c populate_sdk
   * bitbake meta-toolchain-qt5
   * bitbake {image-sdk} using a separate recipe with the options:
   - require {image}.bb
   - IMAGE_FEATURES += " dev-pkgs tools-sdk tools-debug
eclipse-debug debug-tweaks"
   - IMAGE_INSTALL += "kernel-devsrc"
   - inherit populate_sdk populate_sdk_qt5

When I try to use the generated SDKs I get the error below:
Simple helloworld app:
   #include 
   #include 
   #include 
   #include 

   int main (int argc, char** argv)
   {
  printf("Hello World\n");
  return 0;
   }

Compile error:
   ${CC} helloworld.c
   helloworld.c:4:19: fatal error: cstddef: No such file or 
directory

   #include 
^
   compilation terminated

Have I missed a step in generating the SDK?

No, your SDK looks fine. The solution is to just remove the line

#include 

from your c sources or use the g++ compiler (called ${CXX) in
Makefile) to compile the source.

Regards,
vitalEol

Hi Bas,

I'm using the offending line in helloworld.c to highlight the issue
I'm
seeing.

My main program is a Qt application where I see the same issue when
trying to build in QtCreator.

My issue relates to the fact that several include files are not
readily available after 'sourcing' the environment setup.

Do I need to adjust/include other recipes when building the SDK?

I might be wrong, but this looks like you are using the gcc compiler
instead of the g++ one. See the second part of my answer.

To check your environment, check in your sdk that the file cstddef
exists somewhere in /usr/include. Example from a Fedora Linux system:

$ find /usr/include -name cstddef
/usr/include/c++/8/cstddef

If I compile your example with "gcc" on that system, I get the same
error. With "g++", is is fine. It automatically find the cstddef 
header

file in the /usr/include/c++/8 directory.

Hope this helps,

(and please do not top post as that makes a mail thread unreadable)

-- Bas.

Regards,
Evan

Hi Bas,

Apologies for top-posting previously.

using ${CC}, ${CPP} or ${CXX} all show the same error relating to not
finding the required include

cstddef is available in the cross-compiler toolchain:
$ find . -name cstddef
./sysroots/armv7ahf-neon-linux-gnueabi/usr/include/c++/6.2.1/cstddef
./sysroots/armv7ahf-neon-linux-gnueabi/usr/include/boost/compatibility/cpp_c_headers/cstddef

That looks fine.

and is also available on my system:
$ find /usr/include -name cstddef
/usr/include/c++/5/cstddef
/usr/include/c++/4.7/cstddef
/usr/include/c++/4.8/cstddef

${CC} --version && ${CPP} --version && ${CXX} --version
arm-linux-gnueabihf-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There 
is

NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

arm-linux-gnueabihf-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There 
is

NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

arm-linux-gnueabihf-g++ (Linaro GCC 6.2-2016.11) 6.2.1 20161016
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There 
is

NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

I tried with an Freescale i.MX6 SDK for Sumo and that compiled fi

Re: [yocto] Yocto SDK generated - unable to compile application

2018-09-21 Thread Evan O'Loughlin




From: Bas Mevissen [ab...@basmevissen.nl]
Sent: 20 September 2018 23:21
To: Evan O'Loughlin
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto SDK generated - unable to compile application

On 9/20/18 3:32 PM, Evan O'Loughlin wrote:
>
> 
> From: Bas Mevissen [ab...@basmevissen.nl]
> Sent: 20 September 2018 13:23
> To: Evan O'Loughlin
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Yocto SDK generated - unable to compile application
>
> On 2018-09-20 12:28, Evan O'Loughlin wrote:
>> 
>> From: Bas Mevissen [ab...@basmevissen.nl]
>> Sent: 20 September 2018 10:50
>> To: Evan O'Loughlin
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Yocto SDK generated - unable to compile
>> application
>>
>> On 2018-09-20 11:40, Evan O'Loughlin wrote:
>>> -Original Message-
>>> From: Bas Mevissen [mailto:ab...@basmevissen.nl]
>>> Sent: 20 September 2018 10:12
>>> To: Evan O'Loughlin 
>>> Cc: yocto@yoctoproject.org
>>> Subject: Re: [yocto] Yocto SDK generated - unable to compile
>>> application
>>>
>>> On 2018-09-20 10:08, Evan O'Loughlin wrote:
>>>> Hello,
>>>>
>>>> I’m having an issue when I try to use the SDK generated by my yocto
>>>> instance.
>>>> Currently I have yocto set-up to correctly build my image – this all
>>>> works well.
>>>>
>>>> I've built the SDK in the following ways:
>>>>* bitbake {image} –c populate_sdk
>>>>* bitbake meta-toolchain-qt5
>>>>* bitbake {image-sdk} using a separate recipe with the options:
>>>>- require {image}.bb
>>>>- IMAGE_FEATURES += " dev-pkgs tools-sdk tools-debug
>>>> eclipse-debug debug-tweaks"
>>>>- IMAGE_INSTALL += "kernel-devsrc"
>>>>- inherit populate_sdk populate_sdk_qt5
>>>>
>>>>
>>>> When I try to use the generated SDKs I get the error below:
>>>> Simple helloworld app:
>>>>#include 
>>>>#include 
>>>>#include 
>>>>#include 
>>>>
>>>>int main (int argc, char** argv)
>>>>{
>>>>   printf("Hello World\n");
>>>>   return 0;
>>>>}
>>>>
>>>> Compile error:
>>>>${CC} helloworld.c
>>>>helloworld.c:4:19: fatal error: cstddef: No such file or directory
>>>>#include 
>>>> ^
>>>>compilation terminated
>>>>
>>>>
>>>> Have I missed a step in generating the SDK?
>>>>
>>>>
>>>
>>> No, your SDK looks fine. The solution is to just remove the line
>>>
>>> #include 
>>>
>>> from your c sources or use the g++ compiler (called ${CXX) in
>>> Makefile) to compile the source.
>>>
>>>> Regards,
>>>> vitalEol
>>
>>> Hi Bas,
>>>
>>> I'm using the offending line in helloworld.c to highlight the issue
>>> I'm
>>> seeing.
>>>
>>> My main program is a Qt application where I see the same issue when
>>> trying to build in QtCreator.
>>>
>>> My issue relates to the fact that several include files are not
>>> readily available after 'sourcing' the environment setup.
>>>
>>> Do I need to adjust/include other recipes when building the SDK?
>>>
>>
>> I might be wrong, but this looks like you are using the gcc compiler
>> instead of the g++ one. See the second part of my answer.
>>
>> To check your environment, check in your sdk that the file cstddef
>> exists somewhere in /usr/include. Example from a Fedora Linux system:
>>
>> $ find /usr/include -name cstddef
>> /usr/include/c++/8/cstddef
>>
>> If I compile your example with "gcc" on that system, I get the same
>> error. With "g++", is is fine. It automatically find the cstddef header
>> file in the /usr/include/c++/8 directory.
>>
>> Hope this helps,
>>
>> (and please do not top post as that makes a mail thread unreadable)
>>
>> -- Bas.
>>
>>
>>> Regards,
>>> Evan
>>>
>>
>> Hi Bas,
>>
>> Apologies for top-posting previously.
>>
>&g

Re: [yocto] Yocto SDK generated - unable to compile application

2018-09-20 Thread Bas Mevissen




On 9/20/18 3:32 PM, Evan O'Loughlin wrote:
> 
> 
> From: Bas Mevissen [ab...@basmevissen.nl]
> Sent: 20 September 2018 13:23
> To: Evan O'Loughlin
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Yocto SDK generated - unable to compile application
> 
> On 2018-09-20 12:28, Evan O'Loughlin wrote:
>> 
>> From: Bas Mevissen [ab...@basmevissen.nl]
>> Sent: 20 September 2018 10:50
>> To: Evan O'Loughlin
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Yocto SDK generated - unable to compile
>> application
>>
>> On 2018-09-20 11:40, Evan O'Loughlin wrote:
>>> -Original Message-
>>> From: Bas Mevissen [mailto:ab...@basmevissen.nl]
>>> Sent: 20 September 2018 10:12
>>> To: Evan O'Loughlin 
>>> Cc: yocto@yoctoproject.org
>>> Subject: Re: [yocto] Yocto SDK generated - unable to compile
>>> application
>>>
>>> On 2018-09-20 10:08, Evan O'Loughlin wrote:
>>>> Hello,
>>>>
>>>> I’m having an issue when I try to use the SDK generated by my yocto
>>>> instance.
>>>> Currently I have yocto set-up to correctly build my image – this all
>>>> works well.
>>>>
>>>> I've built the SDK in the following ways:
>>>>* bitbake {image} –c populate_sdk
>>>>* bitbake meta-toolchain-qt5
>>>>* bitbake {image-sdk} using a separate recipe with the options:
>>>>- require {image}.bb
>>>>- IMAGE_FEATURES += " dev-pkgs tools-sdk tools-debug
>>>> eclipse-debug debug-tweaks"
>>>>- IMAGE_INSTALL += "kernel-devsrc"
>>>>- inherit populate_sdk populate_sdk_qt5
>>>>
>>>>
>>>> When I try to use the generated SDKs I get the error below:
>>>> Simple helloworld app:
>>>>#include 
>>>>#include 
>>>>#include 
>>>>#include 
>>>>
>>>>int main (int argc, char** argv)
>>>>{
>>>>   printf("Hello World\n");
>>>>   return 0;
>>>>}
>>>>
>>>> Compile error:
>>>>${CC} helloworld.c
>>>>helloworld.c:4:19: fatal error: cstddef: No such file or directory
>>>>#include 
>>>> ^
>>>>compilation terminated
>>>>
>>>>
>>>> Have I missed a step in generating the SDK?
>>>>
>>>>
>>>
>>> No, your SDK looks fine. The solution is to just remove the line
>>>
>>> #include 
>>>
>>> from your c sources or use the g++ compiler (called ${CXX) in
>>> Makefile) to compile the source.
>>>
>>>> Regards,
>>>> vitalEol
>>
>>> Hi Bas,
>>>
>>> I'm using the offending line in helloworld.c to highlight the issue
>>> I'm
>>> seeing.
>>>
>>> My main program is a Qt application where I see the same issue when
>>> trying to build in QtCreator.
>>>
>>> My issue relates to the fact that several include files are not
>>> readily available after 'sourcing' the environment setup.
>>>
>>> Do I need to adjust/include other recipes when building the SDK?
>>>
>>
>> I might be wrong, but this looks like you are using the gcc compiler
>> instead of the g++ one. See the second part of my answer.
>>
>> To check your environment, check in your sdk that the file cstddef
>> exists somewhere in /usr/include. Example from a Fedora Linux system:
>>
>> $ find /usr/include -name cstddef
>> /usr/include/c++/8/cstddef
>>
>> If I compile your example with "gcc" on that system, I get the same
>> error. With "g++", is is fine. It automatically find the cstddef header
>> file in the /usr/include/c++/8 directory.
>>
>> Hope this helps,
>>
>> (and please do not top post as that makes a mail thread unreadable)
>>
>> -- Bas.
>>
>>
>>> Regards,
>>> Evan
>>>
>>
>> Hi Bas,
>>
>> Apologies for top-posting previously.
>>
>> using ${CC}, ${CPP} or ${CXX} all show the same error relating to not
>> finding the required include
>>
>> cstddef is available in the cross-compiler toolchain:
>> $ find . -name cstddef
>> ./s

Re: [yocto] Yocto SDK generated - unable to compile application

2018-09-20 Thread Evan O'Loughlin




From: Bas Mevissen [ab...@basmevissen.nl]
Sent: 20 September 2018 13:23
To: Evan O'Loughlin
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto SDK generated - unable to compile application

On 2018-09-20 12:28, Evan O'Loughlin wrote:
> 
> From: Bas Mevissen [ab...@basmevissen.nl]
> Sent: 20 September 2018 10:50
> To: Evan O'Loughlin
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Yocto SDK generated - unable to compile
> application
>
> On 2018-09-20 11:40, Evan O'Loughlin wrote:
>> -Original Message-
>> From: Bas Mevissen [mailto:ab...@basmevissen.nl]
>> Sent: 20 September 2018 10:12
>> To: Evan O'Loughlin 
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Yocto SDK generated - unable to compile
>> application
>>
>> On 2018-09-20 10:08, Evan O'Loughlin wrote:
>>> Hello,
>>>
>>> I’m having an issue when I try to use the SDK generated by my yocto
>>> instance.
>>> Currently I have yocto set-up to correctly build my image – this all
>>> works well.
>>>
>>> I've built the SDK in the following ways:
>>>* bitbake {image} –c populate_sdk
>>>* bitbake meta-toolchain-qt5
>>>* bitbake {image-sdk} using a separate recipe with the options:
>>>- require {image}.bb
>>>- IMAGE_FEATURES += " dev-pkgs tools-sdk tools-debug
>>> eclipse-debug debug-tweaks"
>>>- IMAGE_INSTALL += "kernel-devsrc"
>>>- inherit populate_sdk populate_sdk_qt5
>>>
>>>
>>> When I try to use the generated SDKs I get the error below:
>>> Simple helloworld app:
>>>#include 
>>>#include 
>>>#include 
>>>#include 
>>>
>>>int main (int argc, char** argv)
>>>{
>>>   printf("Hello World\n");
>>>   return 0;
>>>}
>>>
>>> Compile error:
>>>${CC} helloworld.c
>>>helloworld.c:4:19: fatal error: cstddef: No such file or directory
>>>#include 
>>> ^
>>>compilation terminated
>>>
>>>
>>> Have I missed a step in generating the SDK?
>>>
>>>
>>
>> No, your SDK looks fine. The solution is to just remove the line
>>
>> #include 
>>
>> from your c sources or use the g++ compiler (called ${CXX) in
>> Makefile) to compile the source.
>>
>>> Regards,
>>> vitalEol
>
>> Hi Bas,
>>
>> I'm using the offending line in helloworld.c to highlight the issue
>> I'm
>> seeing.
>>
>> My main program is a Qt application where I see the same issue when
>> trying to build in QtCreator.
>>
>> My issue relates to the fact that several include files are not
>> readily available after 'sourcing' the environment setup.
>>
>> Do I need to adjust/include other recipes when building the SDK?
>>
>
> I might be wrong, but this looks like you are using the gcc compiler
> instead of the g++ one. See the second part of my answer.
>
> To check your environment, check in your sdk that the file cstddef
> exists somewhere in /usr/include. Example from a Fedora Linux system:
>
> $ find /usr/include -name cstddef
> /usr/include/c++/8/cstddef
>
> If I compile your example with "gcc" on that system, I get the same
> error. With "g++", is is fine. It automatically find the cstddef header
> file in the /usr/include/c++/8 directory.
>
> Hope this helps,
>
> (and please do not top post as that makes a mail thread unreadable)
>
> -- Bas.
>
>
>> Regards,
>> Evan
>>
>
> Hi Bas,
>
> Apologies for top-posting previously.
>
> using ${CC}, ${CPP} or ${CXX} all show the same error relating to not
> finding the required include
>
> cstddef is available in the cross-compiler toolchain:
> $ find . -name cstddef
> ./sysroots/armv7ahf-neon-linux-gnueabi/usr/include/c++/6.2.1/cstddef
> ./sysroots/armv7ahf-neon-linux-gnueabi/usr/include/boost/compatibility/cpp_c_headers/cstddef
>

That looks fine.

> and is also available on my system:
> $ find /usr/include -name cstddef
> /usr/include/c++/5/cstddef
> /usr/include/c++/4.7/cstddef
> /usr/include/c++/4.8/cstddef
>
>
> ${CC} --version && ${CPP} --version && ${CXX} --version
> arm-linux-gnueabihf-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
> Copyright (C) 2016 Free Software Foundation, Inc.
> Thi

Re: [yocto] Yocto SDK generated - unable to compile application

2018-09-20 Thread Bas Mevissen

On 2018-09-20 12:28, Evan O'Loughlin wrote:

From: Bas Mevissen [ab...@basmevissen.nl]
Sent: 20 September 2018 10:50
To: Evan O'Loughlin
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto SDK generated - unable to compile 
application

On 2018-09-20 11:40, Evan O'Loughlin wrote:

-Original Message-
From: Bas Mevissen [mailto:ab...@basmevissen.nl]
Sent: 20 September 2018 10:12
To: Evan O'Loughlin 
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto SDK generated - unable to compile
application

On 2018-09-20 10:08, Evan O'Loughlin wrote:

Hello,

I’m having an issue when I try to use the SDK generated by my yocto
instance.
Currently I have yocto set-up to correctly build my image – this all
works well.

I've built the SDK in the following ways:
   * bitbake {image} –c populate_sdk
   * bitbake meta-toolchain-qt5
   * bitbake {image-sdk} using a separate recipe with the options:
   - require {image}.bb
   - IMAGE_FEATURES += " dev-pkgs tools-sdk tools-debug
eclipse-debug debug-tweaks"
   - IMAGE_INSTALL += "kernel-devsrc"
   - inherit populate_sdk populate_sdk_qt5

When I try to use the generated SDKs I get the error below:
Simple helloworld app:
   #include 
   #include 
   #include 
   #include 

   int main (int argc, char** argv)
   {
  printf("Hello World\n");
  return 0;
   }

Compile error:
   ${CC} helloworld.c
   helloworld.c:4:19: fatal error: cstddef: No such file or directory
   #include 
^
   compilation terminated

Have I missed a step in generating the SDK?

No, your SDK looks fine. The solution is to just remove the line

#include 

from your c sources or use the g++ compiler (called ${CXX) in
Makefile) to compile the source.

Regards,
vitalEol

Hi Bas,

I'm using the offending line in helloworld.c to highlight the issue 
I'm

seeing.

My main program is a Qt application where I see the same issue when
trying to build in QtCreator.

My issue relates to the fact that several include files are not
readily available after 'sourcing' the environment setup.

Do I need to adjust/include other recipes when building the SDK?

I might be wrong, but this looks like you are using the gcc compiler
instead of the g++ one. See the second part of my answer.

To check your environment, check in your sdk that the file cstddef
exists somewhere in /usr/include. Example from a Fedora Linux system:

$ find /usr/include -name cstddef
/usr/include/c++/8/cstddef

If I compile your example with "gcc" on that system, I get the same
error. With "g++", is is fine. It automatically find the cstddef header
file in the /usr/include/c++/8 directory.

Hope this helps,

(and please do not top post as that makes a mail thread unreadable)

-- Bas.

Regards,
Evan

Hi Bas,

Apologies for top-posting previously.

using ${CC}, ${CPP} or ${CXX} all show the same error relating to not
finding the required include

cstddef is available in the cross-compiler toolchain:
$ find . -name cstddef
./sysroots/armv7ahf-neon-linux-gnueabi/usr/include/c++/6.2.1/cstddef
./sysroots/armv7ahf-neon-linux-gnueabi/usr/include/boost/compatibility/cpp_c_headers/cstddef

That looks fine.

and is also available on my system:
$ find /usr/include -name cstddef
/usr/include/c++/5/cstddef
/usr/include/c++/4.7/cstddef
/usr/include/c++/4.8/cstddef

${CC} --version && ${CPP} --version && ${CXX} --version
arm-linux-gnueabihf-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is 
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.

arm-linux-gnueabihf-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is 
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.

arm-linux-gnueabihf-g++ (Linaro GCC 6.2-2016.11) 6.2.1 20161016
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is 
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.

I tried with an Freescale i.MX6 SDK for Sumo and that compiled fine with 
${CXX}.

It is a bit of guessing now. Maybe somewhat more information might help:

What version of Yocto are you using? What layers are included? What 
machine?

Are you sure this is the cross compiler belonging to the SDK?

Did you maybe move the SDK install location and not adapt the 
environment file?

Please check this with "echo ${SDKTARGETSYSROOT}" and "echo ${CXX}"

Regards,
Evan

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto SDK generated - unable to compile application

2018-09-20 Thread Evan O'Loughlin

From: Bas Mevissen [ab...@basmevissen.nl]
Sent: 20 September 2018 10:50
To: Evan O'Loughlin
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto SDK generated - unable to compile application

On 2018-09-20 11:40, Evan O'Loughlin wrote:
> -Original Message-
> From: Bas Mevissen [mailto:ab...@basmevissen.nl]
> Sent: 20 September 2018 10:12
> To: Evan O'Loughlin 
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Yocto SDK generated - unable to compile
> application
>
> On 2018-09-20 10:08, Evan O'Loughlin wrote:
>> Hello,
>>
>> I’m having an issue when I try to use the SDK generated by my yocto
>> instance.
>> Currently I have yocto set-up to correctly build my image – this all
>> works well.
>>
>> I've built the SDK in the following ways:
>>* bitbake {image} –c populate_sdk
>>* bitbake meta-toolchain-qt5
>>* bitbake {image-sdk} using a separate recipe with the options:
>>- require {image}.bb
>>- IMAGE_FEATURES += " dev-pkgs tools-sdk tools-debug
>> eclipse-debug debug-tweaks"
>>- IMAGE_INSTALL += "kernel-devsrc"
>>- inherit populate_sdk populate_sdk_qt5
>>
>>
>> When I try to use the generated SDKs I get the error below:
>> Simple helloworld app:
>>#include 
>>#include 
>>#include 
>>#include 
>>
>>int main (int argc, char** argv)
>>{
>>   printf("Hello World\n");
>>   return 0;
>>}
>>
>> Compile error:
>>${CC} helloworld.c
>>helloworld.c:4:19: fatal error: cstddef: No such file or directory
>>#include 
>> ^
>>compilation terminated
>>
>>
>> Have I missed a step in generating the SDK?
>>
>>
>
> No, your SDK looks fine. The solution is to just remove the line
>
> #include 
>
> from your c sources or use the g++ compiler (called ${CXX) in
> Makefile) to compile the source.
>
>> Regards,
>> vitalEol

> Hi Bas,
>
> I'm using the offending line in helloworld.c to highlight the issue I'm
> seeing.
>
> My main program is a Qt application where I see the same issue when
> trying to build in QtCreator.
>
> My issue relates to the fact that several include files are not
> readily available after 'sourcing' the environment setup.
>
> Do I need to adjust/include other recipes when building the SDK?
>

I might be wrong, but this looks like you are using the gcc compiler
instead of the g++ one. See the second part of my answer.

To check your environment, check in your sdk that the file cstddef
exists somewhere in /usr/include. Example from a Fedora Linux system:

$ find /usr/include -name cstddef
/usr/include/c++/8/cstddef

If I compile your example with "gcc" on that system, I get the same
error. With "g++", is is fine. It automatically find the cstddef header
file in the /usr/include/c++/8 directory.

Hope this helps,

(and please do not top post as that makes a mail thread unreadable)

-- Bas.

> Regards,
> Evan
>

Hi Bas,

Apologies for top-posting previously.

using ${CC}, ${CPP} or ${CXX} all show the same error relating to not finding 
the required include

cstddef is available in the cross-compiler toolchain:
$ find . -name cstddef
./sysroots/armv7ahf-neon-linux-gnueabi/usr/include/c++/6.2.1/cstddef
./sysroots/armv7ahf-neon-linux-gnueabi/usr/include/boost/compatibility/cpp_c_headers/cstddef

and is also available on my system:
$ find /usr/include -name cstddef
/usr/include/c++/5/cstddef
/usr/include/c++/4.7/cstddef
/usr/include/c++/4.8/cstddef

${CC} --version && ${CPP} --version && ${CXX} --version
arm-linux-gnueabihf-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

arm-linux-gnueabihf-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

arm-linux-gnueabihf-g++ (Linaro GCC 6.2-2016.11) 6.2.1 20161016
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Regards,
Evan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto SDK generated - unable to compile application

2018-09-20 Thread Bas Mevissen

On 2018-09-20 11:40, Evan O'Loughlin wrote:

-Original Message-
From: Bas Mevissen [mailto:ab...@basmevissen.nl]
Sent: 20 September 2018 10:12
To: Evan O'Loughlin 
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto SDK generated - unable to compile 
application

On 2018-09-20 10:08, Evan O'Loughlin wrote:

Hello,

I’m having an issue when I try to use the SDK generated by my yocto
instance.
Currently I have yocto set-up to correctly build my image – this all
works well.

I've built the SDK in the following ways:
   * bitbake {image} –c populate_sdk
   * bitbake meta-toolchain-qt5
   * bitbake {image-sdk} using a separate recipe with the options:
   - require {image}.bb
   - IMAGE_FEATURES += " dev-pkgs tools-sdk tools-debug
eclipse-debug debug-tweaks"
   - IMAGE_INSTALL += "kernel-devsrc"
   - inherit populate_sdk populate_sdk_qt5

When I try to use the generated SDKs I get the error below:
Simple helloworld app:
   #include 
   #include 
   #include 
   #include 

   int main (int argc, char** argv)
   {
  printf("Hello World\n");
  return 0;
   }

Compile error:
   ${CC} helloworld.c
   helloworld.c:4:19: fatal error: cstddef: No such file or directory
   #include 
^
   compilation terminated

Have I missed a step in generating the SDK?

No, your SDK looks fine. The solution is to just remove the line

#include 

from your c sources or use the g++ compiler (called ${CXX) in
Makefile) to compile the source.

Regards,
vitalEol

Hi Bas,

I'm using the offending line in helloworld.c to highlight the issue I'm 
seeing.

My main program is a Qt application where I see the same issue when
trying to build in QtCreator.

My issue relates to the fact that several include files are not
readily available after 'sourcing' the environment setup.

Do I need to adjust/include other recipes when building the SDK?

I might be wrong, but this looks like you are using the gcc compiler 
instead of the g++ one. See the second part of my answer.

To check your environment, check in your sdk that the file cstddef 
exists somewhere in /usr/include. Example from a Fedora Linux system:

$ find /usr/include -name cstddef
/usr/include/c++/8/cstddef

If I compile your example with "gcc" on that system, I get the same 
error. With "g++", is is fine. It automatically find the cstddef header 
file in the /usr/include/c++/8 directory.

Hope this helps,

(and please do not top post as that makes a mail thread unreadable)

-- Bas.

Regards,
Evan

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto SDK generated - unable to compile application

2018-09-20 Thread Evan O'Loughlin

Hi Bas,

I'm using the offending line in helloworld.c to highlight the issue I'm seeing.

My main program is a Qt application where I see the same issue when trying to 
build in QtCreator.

My issue relates to the fact that several include files are not readily 
available after 'sourcing' the environment setup.

Do I need to adjust/include other recipes when building the SDK?

Regards,
Evan

-Original Message-
From: Bas Mevissen [mailto:ab...@basmevissen.nl] 
Sent: 20 September 2018 10:12
To: Evan O'Loughlin 
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto SDK generated - unable to compile application

On 2018-09-20 10:08, Evan O'Loughlin wrote:
> Hello,
> 
> I’m having an issue when I try to use the SDK generated by my yocto 
> instance.
> Currently I have yocto set-up to correctly build my image – this all 
> works well.
> 
> I've built the SDK in the following ways:
>* bitbake {image} –c populate_sdk
>* bitbake meta-toolchain-qt5
>* bitbake {image-sdk} using a separate recipe with the options:
>- require {image}.bb
>- IMAGE_FEATURES += " dev-pkgs tools-sdk tools-debug 
> eclipse-debug debug-tweaks"
>- IMAGE_INSTALL += "kernel-devsrc"
>- inherit populate_sdk populate_sdk_qt5
> 
> 
> When I try to use the generated SDKs I get the error below:
> Simple helloworld app:
>#include 
>#include 
>#include 
>#include 
> 
>int main (int argc, char** argv)
>{
>   printf("Hello World\n");
>   return 0;
>}
> 
> Compile error:
>${CC} helloworld.c
>helloworld.c:4:19: fatal error: cstddef: No such file or directory
>#include 
> ^
>compilation terminated
> 
> 
> Have I missed a step in generating the SDK?
> 
> 

No, your SDK looks fine. The solution is to just remove the line

#include 

from your c sources or use the g++ compiler (called ${CXX) in Makefile) to 
compile the source.

> Regards,
> vitalEol

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto SDK generated - unable to compile application

2018-09-20 Thread Bas Mevissen


On 2018-09-20 10:08, Evan O'Loughlin wrote:

Hello,

I’m having an issue when I try to use the SDK generated by my yocto 
instance.
Currently I have yocto set-up to correctly build my image – this all 
works well.


I've built the SDK in the following ways:
   * bitbake {image} –c populate_sdk
   * bitbake meta-toolchain-qt5
   * bitbake {image-sdk} using a separate recipe with the options:
   - require {image}.bb
   - IMAGE_FEATURES += " dev-pkgs tools-sdk tools-debug
eclipse-debug debug-tweaks"
   - IMAGE_INSTALL += "kernel-devsrc"
   - inherit populate_sdk populate_sdk_qt5


When I try to use the generated SDKs I get the error below:
Simple helloworld app:
   #include 
   #include 
   #include 
   #include 

   int main (int argc, char** argv)
   {
  printf("Hello World\n");
  return 0;
   }

Compile error:
   ${CC} helloworld.c
   helloworld.c:4:19: fatal error: cstddef: No such file or directory
   #include 
^
   compilation terminated


Have I missed a step in generating the SDK?




No, your SDK looks fine. The solution is to just remove the line

#include 

from your c sources or use the g++ compiler (called ${CXX) in Makefile) 
to compile the source.



Regards,
vitalEol


--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto SDK generated - unable to compile application

2018-09-20 Thread Evan O'Loughlin

Hello,

I’m having an issue when I try to use the SDK generated by my yocto instance.
Currently I have yocto set-up to correctly build my image – this all works well.

I've built the SDK in the following ways:
   * bitbake {image} –c populate_sdk
   * bitbake meta-toolchain-qt5
   * bitbake {image-sdk} using a separate recipe with the options:
   - require {image}.bb
   - IMAGE_FEATURES += " dev-pkgs tools-sdk tools-debug eclipse-debug 
debug-tweaks"
   - IMAGE_INSTALL += "kernel-devsrc"
   - inherit populate_sdk populate_sdk_qt5


When I try to use the generated SDKs I get the error below:
Simple helloworld app:
   #include 
   #include 
   #include 
   #include 
   
   int main (int argc, char** argv)
   {
  printf("Hello World\n");
  return 0;
   }

Compile error:
   ${CC} helloworld.c 
   helloworld.c:4:19: fatal error: cstddef: No such file or directory
   #include 
^
   compilation terminated


Have I missed a step in generating the SDK?


Regards,
vitalEol
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Eclipse/Yocto SDK cannot import Makefile based projects

2018-08-23 Thread Ayoub Zaki

I'm using Eclipse Oxygen and set it up succesffuly with Yocto Plugins and
SDK toolchains ( 2.5 Sumo).

I can create a  Yocto SDK Autotools Project but there is no way to import
an existing Makefile based project and use the Yocto SDK plugin !

am I missing something ?


best regards
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK and out of tree modules

2018-08-01 Thread RUSSELL PETERSON

I have started looking at this more closely and I have a few questions. Hope 
someone knows or has seen these issues before.

1. When running create_filtered task list I see failures. This is mainly due to 
the fact that the sdkbasepath getting renamed to tmp-renamed-sdk fails. I have 
bypassed this to get around it but it seems like it should work. Renaming 
<...>/sdk-ext/image/opt/poky/2.4.1 to <...>sdk-ext/image/tmp-renamed-sdk 
doesn't seem to work.

2. Understanding the sstate-cache took some time but I think I understand the 
basic idea now. The problem I was seeing relates to the fact that my build 
directory and my temp directory are on different disks. Hence, when I delete 
the build directory, the cache gets deleted. I would think that making 
core-image-full again would regenerate the sstate-cache but it does not. The 
only way I see the sstate-cache regenerated is by deleting the tmp directory 
completely and starting over. Without the cache, building the sdk-ext fails 
with about 5000 "should have been setscened" errors. As the ext sdk clearly has 
a dependency there... why isn't the state cache re-created?? Probably just 
don't quite understand state yet, I guess.

3. Finally, I have the ext sdk built... tried to install it... failed with an 
error telling me TMPDIR has changed and I need to rebuild or change it back. I 
assume this is related to me setting TMPDIR in the original local.conf? Anyone 
else see this? Seems like unless TMPDIR is set to the default (TOPDIR/tmp) the 
SDK won't work??

Regards,

Russell

> On July 25, 2018 at 9:01 AM RUSSELL PETERSON  wrote:
>
>
> So, this seems broken to me. I managed to get around this issue 
> (sstate-control/manifest-allarch-kernel-devsrc.populate_sysroot not found?) 
> by appending PACKAGE_EXTRA_ARCHS with the MACHINE_ARCH for my bsp. While 
> PACKAGE_ARCHS now has a duplicate in it (it already includes MACHINE_ARCH as 
> well as PACKAGE_EXTRA_ARCH), the python code in staging_populate_sysroot 
> seems to require this or it looks for the wrong manifest file.
>
> Also, when building the eSDK, dnf seems very confused about what packages are 
> compatible. It's looking for my SoC arch packages... but then won't accept 
> aarch64 as being compatible. I needed to set:
>
> ALL_MULTILIB_PACKAGE_ARCHS =+ " ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}"
>
> to get /etc/dnf/vars/arch to update correctly. This is a bit tedious. I'm now 
> having a similar issue because dnf doesn't seem to like an arch of 
> x86_64-nativesdk. Do I update ALL_MULTILIB_PACKAGE_ARCHS again?? Ug.
>
> --Russ
>
>
> > On July 24, 2018 at 8:36 AM RUSSELL PETERSON  wrote:
> >
> >
> > I am running Poky Rocko at the HEAD (just updated yesterday) and see the 
> > following when I attempt to build the eSDK:
> >
> > sstate-control/manifest-allarch-kernel-devsrc.populate_sysroot not found?
> >
> > I see this has been an issue with others as well. It looks like Paul had a 
> > fix around April but then the trail went silent so I'm not sure if there 
> > was a fix or if that fix went into Rocko. Anyone?
> >
> > --Russ
> >
> > > On July 21, 2018 at 4:42 PM Russell Peterson  
> > > wrote:
> > >
> > >
> > > No, just the standard SDK. I was having issues building the eSDK back 
> > > when we used pyro and never fully figured it out… but we have since 
> > > upgraded to rocko. I should revisit the eSDK and see if it works for me 
> > > now or find the root cause since it sounds useful.
> > >
> > > Thanks, Khem.
> > >
> > > —Russ
> > >
> > >
> > > > On Jul 21, 2018, at 1:34 PM, Khem Raj  wrote:
> > > >
> > > > On Sat, Jul 21, 2018 at 6:20 AM Russell Peterson 
> > > >  wrote:
> > > >>
> > > >> Hello,
> > > >>
> > > >> I have been building some modules using the SDK for a while now. This 
> > > >> is mostly for development flow purposes but we have had a few 
> > > >> customers doing this as well. To get this to work we always need to 
> > > >> run “make silentoldconfig scripts” inside the RFS of the SDK on the 
> > > >> build host. Many folks forget to do this this and thus many, many 
> > > >> questions come my way about the SDK being broken and they can’t build 
> > > >> their modules (not all users are kernel experts or even intermediates… 
> > > >> they just want to apply a patch and quickly move on to their app). Is 
> > > >> there a way to do this auto-magically during the installation of the 
> > > >> SDK by adding some type of scripts etc… to the recipe? I assume it 
> > > >> needs to be done at install time since while the build host is x86… 
> > > >> the exact linux distro is not known until then (or does that matter?).
> > > >>
> > > >
> > > > are you using extensible SDK ? in that case I think do_make_scripts
> > > > from module-base.bbclass should be helpful
> > > >
> > > >> —Russ
> > > >>
> > > >> --
> > > >> ___
> > > >> yocto mailing list
> > > >> yocto@yoctoproject.org
> > > >> https://lists.yoctoproject.org/listinfo/yocto
> > >
> > > --
>

Re: [yocto] SDK and out of tree modules

2018-07-25 Thread RUSSELL PETERSON

So, this seems broken to me.  I managed to get around this issue 
(sstate-control/manifest-allarch-kernel-devsrc.populate_sysroot not found?) by 
appending PACKAGE_EXTRA_ARCHS with the MACHINE_ARCH for my bsp.  While 
PACKAGE_ARCHS now has a duplicate in it (it already includes MACHINE_ARCH as 
well as PACKAGE_EXTRA_ARCH), the python code in staging_populate_sysroot seems 
to require this or it looks for the wrong manifest file.

Also, when building the eSDK, dnf seems very confused about what packages are 
compatible.  It's looking for my SoC arch packages... but then won't accept 
aarch64 as being compatible.  I needed to set:

ALL_MULTILIB_PACKAGE_ARCHS =+ " ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}"

to get /etc/dnf/vars/arch to update correctly.  This is a bit tedious.  I'm now 
having a similar issue because dnf doesn't seem to like an arch of 
x86_64-nativesdk.  Do I update ALL_MULTILIB_PACKAGE_ARCHS again??  Ug.

--Russ
 

> On July 24, 2018 at 8:36 AM RUSSELL PETERSON  wrote:
> 
> 
> I am running Poky Rocko at the HEAD (just updated yesterday) and see the 
> following when I attempt to build the eSDK:
> 
> sstate-control/manifest-allarch-kernel-devsrc.populate_sysroot not found?
> 
> I see this has been an issue with others as well.  It looks like Paul had a 
> fix around April but then the trail went silent so I'm not sure if there was 
> a fix or if that fix went into Rocko.  Anyone?
> 
> --Russ
> 
> > On July 21, 2018 at 4:42 PM Russell Peterson  wrote:
> > 
> > 
> > No, just the standard SDK.  I was having issues building the eSDK back when 
> > we used pyro and never fully figured it out… but we have since upgraded to 
> > rocko.  I should revisit the eSDK and see if it works for me now or find 
> > the root cause since it sounds useful.
> > 
> > Thanks, Khem.
> > 
> > —Russ
> > 
> > 
> > > On Jul 21, 2018, at 1:34 PM, Khem Raj  wrote:
> > > 
> > > On Sat, Jul 21, 2018 at 6:20 AM Russell Peterson  
> > > wrote:
> > >> 
> > >> Hello,
> > >> 
> > >> I have been building some modules using the SDK for a while now.  This 
> > >> is mostly for development flow purposes but we have had a few customers 
> > >> doing this as well.  To get this to work we always need to run “make 
> > >> silentoldconfig scripts” inside the RFS of the SDK on the build host.  
> > >> Many folks forget to do this this and thus many, many questions come my 
> > >> way about the SDK being broken and they can’t build their modules (not 
> > >> all users are kernel experts or even intermediates… they just want to 
> > >> apply a patch and quickly move on to their app).  Is there a way to do 
> > >> this auto-magically during the installation of the SDK by adding some 
> > >> type of scripts etc… to the recipe?  I assume it needs to be done at 
> > >> install time since while the build host is x86… the exact linux distro 
> > >> is not known until then (or does that matter?).
> > >> 
> > > 
> > > are you using extensible SDK ? in that case I think do_make_scripts
> > > from module-base.bbclass should be helpful
> > > 
> > >> —Russ
> > >> 
> > >> --
> > >> ___
> > >> yocto mailing list
> > >> yocto@yoctoproject.org
> > >> https://lists.yoctoproject.org/listinfo/yocto
> > 
> > -- 
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK and out of tree modules

2018-07-24 Thread RUSSELL PETERSON

I am running Poky Rocko at the HEAD (just updated yesterday) and see the 
following when I attempt to build the eSDK:

sstate-control/manifest-allarch-kernel-devsrc.populate_sysroot not found?

I see this has been an issue with others as well.  It looks like Paul had a fix 
around April but then the trail went silent so I'm not sure if there was a fix 
or if that fix went into Rocko.  Anyone?

--Russ

> On July 21, 2018 at 4:42 PM Russell Peterson  wrote:
> 
> 
> No, just the standard SDK.  I was having issues building the eSDK back when 
> we used pyro and never fully figured it out… but we have since upgraded to 
> rocko.  I should revisit the eSDK and see if it works for me now or find the 
> root cause since it sounds useful.
> 
> Thanks, Khem.
> 
> —Russ
> 
> 
> > On Jul 21, 2018, at 1:34 PM, Khem Raj  wrote:
> > 
> > On Sat, Jul 21, 2018 at 6:20 AM Russell Peterson  
> > wrote:
> >> 
> >> Hello,
> >> 
> >> I have been building some modules using the SDK for a while now.  This is 
> >> mostly for development flow purposes but we have had a few customers doing 
> >> this as well.  To get this to work we always need to run “make 
> >> silentoldconfig scripts” inside the RFS of the SDK on the build host.  
> >> Many folks forget to do this this and thus many, many questions come my 
> >> way about the SDK being broken and they can’t build their modules (not all 
> >> users are kernel experts or even intermediates… they just want to apply a 
> >> patch and quickly move on to their app).  Is there a way to do this 
> >> auto-magically during the installation of the SDK by adding some type of 
> >> scripts etc… to the recipe?  I assume it needs to be done at install time 
> >> since while the build host is x86… the exact linux distro is not known 
> >> until then (or does that matter?).
> >> 
> > 
> > are you using extensible SDK ? in that case I think do_make_scripts
> > from module-base.bbclass should be helpful
> > 
> >> —Russ
> >> 
> >> --
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
> 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK and out of tree modules

2018-07-21 Thread Russell Peterson

No, just the standard SDK.  I was having issues building the eSDK back when we 
used pyro and never fully figured it out… but we have since upgraded to rocko.  
I should revisit the eSDK and see if it works for me now or find the root cause 
since it sounds useful.

Thanks, Khem.

—Russ


> On Jul 21, 2018, at 1:34 PM, Khem Raj  wrote:
> 
> On Sat, Jul 21, 2018 at 6:20 AM Russell Peterson  
> wrote:
>> 
>> Hello,
>> 
>> I have been building some modules using the SDK for a while now.  This is 
>> mostly for development flow purposes but we have had a few customers doing 
>> this as well.  To get this to work we always need to run “make 
>> silentoldconfig scripts” inside the RFS of the SDK on the build host.  Many 
>> folks forget to do this this and thus many, many questions come my way about 
>> the SDK being broken and they can’t build their modules (not all users are 
>> kernel experts or even intermediates… they just want to apply a patch and 
>> quickly move on to their app).  Is there a way to do this auto-magically 
>> during the installation of the SDK by adding some type of scripts etc… to 
>> the recipe?  I assume it needs to be done at install time since while the 
>> build host is x86… the exact linux distro is not known until then (or does 
>> that matter?).
>> 
> 
> are you using extensible SDK ? in that case I think do_make_scripts
> from module-base.bbclass should be helpful
> 
>> —Russ
>> 
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK and out of tree modules

2018-07-21 Thread Khem Raj

On Sat, Jul 21, 2018 at 6:20 AM Russell Peterson  wrote:
>
> Hello,
>
> I have been building some modules using the SDK for a while now.  This is 
> mostly for development flow purposes but we have had a few customers doing 
> this as well.  To get this to work we always need to run “make 
> silentoldconfig scripts” inside the RFS of the SDK on the build host.  Many 
> folks forget to do this this and thus many, many questions come my way about 
> the SDK being broken and they can’t build their modules (not all users are 
> kernel experts or even intermediates… they just want to apply a patch and 
> quickly move on to their app).  Is there a way to do this auto-magically 
> during the installation of the SDK by adding some type of scripts etc… to the 
> recipe?  I assume it needs to be done at install time since while the build 
> host is x86… the exact linux distro is not known until then (or does that 
> matter?).
>

are you using extensible SDK ? in that case I think do_make_scripts
from module-base.bbclass should be helpful

> —Russ
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] SDK and out of tree modules

2018-07-21 Thread Russell Peterson

Hello,

I have been building some modules using the SDK for a while now.  This is 
mostly for development flow purposes but we have had a few customers doing this 
as well.  To get this to work we always need to run “make silentoldconfig 
scripts” inside the RFS of the SDK on the build host.  Many folks forget to do 
this this and thus many, many questions come my way about the SDK being broken 
and they can’t build their modules (not all users are kernel experts or even 
intermediates… they just want to apply a patch and quickly move on to their 
app).  Is there a way to do this auto-magically during the installation of the 
SDK by adding some type of scripts etc… to the recipe?  I assume it needs to be 
done at install time since while the build host is x86… the exact linux distro 
is not known until then (or does that matter?).

—Russ

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Issue in extracting Yocto Sdk

2018-07-09 Thread Burton, Ross

Some comments inline, including where I think your problem is:

On 9 July 2018 at 10:04, AKASH BHARDWAJ  wrote:

> LICENSE = "CLOSED"
>>
>
Why are you setting LICENSE in local.conf?


> PACKAGE_FEED_URIS = " http://git.yoctoproject.org/cgit/cgit.cgi/meta-
>> raspberrypi/tree/recipes-devtools/wiringPi/wiringpi_git.bb?h=master
>> https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/
>> recipes-devtools/i2c-tools/i2c-tools_4.0.bb https://github.com/
>> eMakerStudio/meta-rpi/tree/morty/recipes-devtools/pi-
>> blaster/pi-blaster_git.bbappend https://git.pengutronix.de/
>> cgit/imx/sdma-firmware"
>>
>
This isn't what PACKAGE_FEED_URIS is for


> DISTRO_FEATURES_append += "virtualization"
>>
>
Missing whitespace before virtualization when using append.


> IMAGE_INSTALL = "packagegroup-core-boot \
>> packagegroup-core-x11 \
>> packagegroup-lxde-base \
>> kernel-modules \
>> "
>>
>
Why are you overriding IMAGE_INSTALL in local.conf?  Write your own image
recipe.


> PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk "
>>
>
You only need to put more than one entry here if you're testing the
packaging infrastructure, you can remove the entries you don't use.

PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk "
>>
>
Again.

TOOLCHAIN_HOST_TASK += "nativesdk-cmake-dev"
>>
>
I suspect that here you are overriding the default value which is set using
?=, which is why you have a broken SDK.  Use _append.


> IMAGE_INSTALL_APPEND = "git apt dpkg opkg rpm sudo wiringpi wiringpi-dev
>> cmake connman connman-client tzdata i2c-tools i2c-tools-dev  pi-blaster
>> pi-blaster-dev"
>>
>
That's not a variable anything uses.


> CORE_IMAGE_EXTRA_INSTALL=" rpm opkg dpkg git sudo wiringpi apt
>> wiringpi-dev cmake tzdata localedef i2c-tools i2c-tools-dev connman
>> connman-client  pi-blaster pi-blaster-dev"
>>
>
Unused as you're resetting IMAGE_INSTALL above.

I strongly recommend that you make your own distro file for distro-wide
configuration (distro features, etc) and then your own image recipe.
Jamming everything into local.conf just gets messy and unmaintainable.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Issue in extracting Yocto Sdk

2018-07-09 Thread AKASH BHARDWAJ

./poky-glibc-x86_64-rpi-basic-image-cortexa7hf-neon-vfpv4-toolchain-2.4.3.sh
Poky (Yocto Project Reference Distro) SDK installer version 2.4.3
=
Enter target directory for SDK (default: /opt/poky/2.4.3):
/home/akash/rpil/rpi-build/tmp
The directory "/home/akash/rpil/rpi-build/tmp" already contains a SDK for
this architecture.
If you continue, existing files will be overwritten! Proceed[y/N]? y
Extracting SDK.
...done
Setting it up...SDK could not be set up. Relocate script unable to find
ld-linux.so. Abort!

Presently,I am facing this issue.How can I rectify it?


Here is the local.conf file

CONF_VERSION = "1"
> DESCRIPTION = "Yocto-image"
> # Local configuration for meta-rpi images
> # Yocto Project 2.4 Poky distribution [rocko] branch
> # This is a sysvinit system
>
> LICENSE = "CLOSED"
>
> BBMASK = "meta-raspberrypi/recipes-kernel/linux-firmware"
>
> PACKAGE_FEED_URIS = "
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/recipes-devtools/wiringPi/wiringpi_git.bb?h=master
> https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-devtools/i2c-tools/i2c-tools_4.0.bb
> https://github.com/eMakerStudio/meta-rpi/tree/morty/recipes-devtools/pi-blaster/pi-blaster_git.bbappend
> https://git.pengutronix.de/cgit/imx/sdma-firmware";
>
> DISTRO_FEATURES = "ext2 pam opengl usbhost ${DISTRO_FEATURES_LIBC}  x11
> wayland"
>
> DISTRO_FEATURES_BACKFILL_CONSIDERED += "pulseaudio"
> DISTRO_FEATURES_append += "virtualization"
>
> IMAGE_INSTALL = "packagegroup-core-boot \
> packagegroup-core-x11 \
> packagegroup-lxde-base \
> kernel-modules \
> "
>
> PREFERRED_PROVIDER_jpeg = "libjpeg-turbo"
> PREFERRED_PROVIDER_jpeg-native = "libjpeg-turbo-native"
>
> PREFERRED_PROVIDER_udev = "eudev"
> VIRTUAL-RUNTIME_init_manager = "sysvinit"
>
> MACHINE_FEATURES_remove = "apm"
>
> IMAGE_FSTYPES = "tar.xz ext3 rpi-sdimg "
>
> # override the meta-raspberrypi default 4.9 kernel
> PREFERRED_VERSION_linux-raspberrypi = "4.14%"
>
> # Choose the board you are building for
> #MACHINE="raspberrypi"
> #MACHINE="raspberrypi0"
> #MACHINE="raspberrypi0-wifi"
> #MACHINE="raspberrypi2"
> MACHINE = "raspberrypi3"
> #MACHINE="raspberrypi-cm"
> #MACHINE="raspberrypi-cm3"
>
> # Choices are Image or zImage if NOT using u-boot (no u-boot is the
> default)
> # Choices are uImage or zImage if using u-boot, though if you choose zImage
> # with u-boot you will also have to change the boot script boot command
> KERNEL_IMAGETYPE = "zImage"
>
> ENABLE_UART="1"
>
> #DL_DIR = "${HOME}/oe-sources"
>
> #SSTATE_DIR = "/oe4/rpi/sstate-cache"
>
> #TMPDIR = "/oe4/rpi/tmp-rocko"
>
> DISTRO = "poky"
> PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk "
>
> # i686 or x86_64
> SDKMACHINE = "x86_64"
>
> #EXTRA_IMAGE_FEATURES = "debug-tweaks"
>
>
>
> PACKAGECONFIG_append_pn-qemu-native = " sdl"
> PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
> USER_CLASSES = "image-mklibs image-prelink"
>
> PATCHRESOLVE = "noop"
>
> RM_OLD_IMAGE = "1"
>
> INHERIT += "rm_work"
>
>
>
>
> PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk "
>
>
> EXTRA_IMAGE_FEATURES += "tools-sdk tools-debug eclipse-debug tools-profile
> debug-tweaks "
>
> EXTRA_IMAGE_FEATURES += " package-management dev-pkgs "
>
> USER_CLASSES ?= "buildstats image-mklibs"
>
>
>
>
>
>
>
>
>
>
> GPU_MEM = "16"
>
>
> TOOLCHAIN_HOST_TASK += "nativesdk-cmake-dev"
> TOOLCHAIN_TARGET_TASK_append = " wiringpi-dev"
>
>
> IMAGE_INSTALL_APPEND = "git apt dpkg opkg rpm sudo wiringpi wiringpi-dev
> cmake connman connman-client tzdata i2c-tools i2c-tools-dev  pi-blaster
> pi-blaster-dev"
> CORE_IMAGE_EXTRA_INSTALL=" rpm opkg dpkg git sudo wiringpi apt
> wiringpi-dev cmake tzdata localedef i2c-tools i2c-tools-dev connman
> connman-client  pi-blaster pi-blaster-dev"
> IMAGE_INSTALL_append += "  bluez5 i2c-tools python-smbus bridge-utils
> hostapd dhcp-server iptables wpa-supplicant apache2  glibc-utils"
> ENABLE_UART="1"
> ENABLE_SPI_BUS= "1"
> ENABLE_I2C = "1"
> ENABLE_PCF857x_I2C_GPIO_expanders = "1"
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto Sdk

2018-07-08 Thread Khem Raj

On Sun, Jul 8, 2018 at 1:56 PM AKASH BHARDWAJ  wrote:
>
> How to add ld-linux.so.2 for Extracting Yocto SDK,as while extracting glibc- 
> poky-cortexch-rpi-basic-image-toolchain.sh ,it shows that ld-linux.so.2.
> While examining the directories,I found out that ld-linux-armeh4.so is 
> present but ld-linux.so.2 is not present,how can I add it?How can I rectify 
> this issue?
>

You should describe your problem here. dynamic linker names are
associated with architecture and ABIs, it might
be that you need a SDK with different ABI or architecture,

> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Sdk

2018-07-08 Thread AKASH BHARDWAJ

How to add ld-linux.so.2 for Extracting Yocto SDK,as while extracting
glibc- poky-cortexch-rpi-basic-image-toolchain.sh ,it shows that
ld-linux.so.2.
While examining the directories,I found out that ld-linux-armeh4.so is
present but ld-linux.so.2 is not present,how can I add it?How can I rectify
this issue?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto SDK and license manifest

2018-06-26 Thread Michael Habibi

We use Yocto to generate a simple SDK that we use as a toolchain. However,
it appears that building the SDK vs an image does not generate the license
manifest (we have deploy/rpm, deploy/sdk, but not deploy/license).

Have we configured something wrong, or perhaps do we need to do something
additional to have the license manifest as well?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto SDK & toolchain deploy issue

2018-05-24 Thread techi eth

I would like to use SDK’s & tool chain generated from Yocto to some other
PC. I see following difficulty while using.



1)  Path in *environment-setup-cortexa8hf-vfp-neon-poky-linux-gnueabi*
is hard code. Is it possible to have that is configurable.

2)  If I change path in *environment-setup-cortexa8hf-vfp-neon-poky-linux-
gnueabi script *than also it raise error while recognizing compiler*.*



Please let me know hint for using tool chain generated from one machine to
other machine at any path.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto SDK & Toolchain Deploy Issue

2018-05-22 Thread Anuj Mittal

On 05/22/2018 12:23 PM, techi eth wrote:
> I would like to use SDK’s & tool chain generated from Yocto to some
> other PC. I see following difficulty while using.
> 
>  
> 
> 1)  Path
> in *environment-setup-cortexa8hf-vfp-neon-poky-linux-gnueabi* is hard
> code. Is it possible to have that is configurable.

You will have to install the SDK using the sh file that is generated on
that other machine that you're planning to use.

Please see this and the sections around it:

https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#sdk-installing-the-sdk

If this doesn't answer your question, then as Alex mentioned, please
include more details on what you are doing and the steps.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto SDK & Toolchain Deploy Issue

2018-05-22 Thread Khem Raj

On Tue, May 22, 2018 at 12:23 AM, techi eth  wrote:
> I would like to use SDK’s & tool chain generated from Yocto to some other
> PC. I see following difficulty while using.
>
>
>
> 1)  Path in environment-setup-cortexa8hf-vfp-neon-poky-linux-gnueabi is
> hard code. Is it possible to have that is configurable.
>
> 2)  If I change path in
> environment-setup-cortexa8hf-vfp-neon-poky-linux- gnueabi script than also
> it raise error while recognizing compiler.
>
>
>
> Please let me know hint for using tool chain generated from one machine to
> other machine at any path.

I dont think these are reasonable ways of using SDK. The env script is provided
so you can have an environment to use the SDK correctly. I would recommend
that you look into the problem differently where you adopt the app framework
to use the environment given by SDK
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto SDK & Toolchain Deploy Issue

2018-05-22 Thread Alexander Kanavin


On 05/22/2018 03:27 PM, techi eth wrote:
Can anyone give me hint on above point. I think it will be something 
basic while populating SDK's.

Please let  me know if any information needed.


Can I give you a tip? Introduce yourself properly. What is your name, 
what company you work for, and what is the product. Also, have a bit of 
patience. Asking the same questions hours after the first time makes it 
less likely someone will respond, not more.


Alex
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto SDK & Toolchain Deploy Issue

2018-05-22 Thread techi eth

Hi,

Can anyone give me hint on above point. I think it will be something basic
while populating SDK's.
Please let  me know if any information needed.

Thanks



On Tue, May 22, 2018 at 9:53 AM, techi eth  wrote:

> I would like to use SDK’s & tool chain generated from Yocto to some other
> PC. I see following difficulty while using.
>
>
>
> 1)  Path in *environment-setup-cortexa8hf-vfp-neon-poky-linux-gnueabi*
>  is hard code. Is it possible to have that is configurable.
>
> 2)  If I change path in *environment-setup-cortexa8hf-vfp-neon-poky-linux-
> gnueabi script *than also it raise error while recognizing compiler*.*
>
>
>
> Please let me know hint for using tool chain generated from one machine to
> other machine at any path.
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto SDK & Toolchain Deploy Issue

2018-05-21 Thread techi eth

I would like to use SDK’s & tool chain generated from Yocto to some other
PC. I see following difficulty while using.



1)  Path in *environment-setup-cortexa8hf-vfp-neon-poky-linux-gnueabi* is
hard code. Is it possible to have that is configurable.

2)  If I change path in *environment-setup-cortexa8hf-vfp-neon-poky-linux-
gnueabi script *than also it raise error while recognizing compiler*.*



Please let me know hint for using tool chain generated from one machine to
other machine at any path.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] sdk compiler output usable during build?

2018-04-23 Thread Janne Karhunen

Hi,

Quick question - is the sdk compiler supposed to be able to create
executables that can be executed while the sdk package build is
ongoing?

Reason I'm asking is that my package nativesdk build errors out saying
'C compiler cannot create executables'. Reason for that seems to be
that the output (say a.out) generated by x86_64-pokysdk-linux-gcc
requests runtime linker from the SDKs default final resting place
(/opt/poky..) and not from the location where the sysroot lies during
the build. How is that supposed to work?


--
Janne
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] sdk package build question

2018-04-23 Thread Janne Karhunen

Hi,

Quick question - is the sdk compiler supposed to be able to create
executables that can be executed while the sdk package build is
ongoing?

Reason I'm asking is that my package nativesdk build errors out saying
'C compiler cannot create executables'. Reason for that seems to be
that the output (say a.out) generated by x86_64-pokysdk-linux-gcc
requests runtime linker from the SDKs final resting place
(/opt/poky..) and not from the location where the sysroot lies during
the build. How is that supposed to work?


--
Janne
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK without qemu

2018-03-07 Thread Avishay Orpaz

Yes, that's right. I only need the sysroot and the build tools (gcc etc.). I'm 
not planning to work with my software on an emulator.

From: Burton, Ross 
Sent: Tuesday, March 6, 2018 1:15:29 PM
To: Avishay Orpaz
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] SDK without qemu

Do you mean "how can I build a SDK without using qemu" or "how can I build a 
SDK that doesn't contain qemu"?

On 5 March 2018 at 15:37, Avishay Orpaz 
mailto:avis...@magosys.com>> wrote:

Is there a way to build an SDK without qemu?

Avishay

--
___
yocto mailing list
yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK without qemu

2018-03-06 Thread Burton, Ross

Do you mean "how can I build a SDK without using qemu" or "how can I build
a SDK that doesn't contain qemu"?

On 5 March 2018 at 15:37, Avishay Orpaz  wrote:

> Is there a way to build an SDK without qemu?
>
>
> Avishay
>
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] SDK without qemu

2018-03-06 Thread Avishay Orpaz

Is there a way to build an SDK without qemu?


Avishay


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] install qcharts module to yocto sdk

2018-02-07 Thread Pehen Azam

Hi!
I try to cross-compile qt chart examples for a yocto platform. I do
following steps to compile my qt programs:

 - source /opt/myimage/2.1.2/environment-setup-cortexa9hf-
neon-poky-linux-gnueabi
 - qmake -o Makefile areachart.pro
 - make

But When I add `QT += charts` to any project run qmake like `qmake -o
Makefile areachart.pro` I hit this error:
Project ERROR: Unknown module(s) in QT: charts

Here is the output of `qmake -v`:
QMake version 3.0
Using Qt version 5.7.0 in /opt/myimage/2.1.2/sysroots/
cortexa9hf-neon-poky-linux-gnueabi/usr/lib

Should I should add `qtcharts` module my yocto SDK to be able to compile
the example? if yes how?

For some reasons I was able to cross-compiled Qt from source on github
using `qtcreator` and get the binary files for qt examples and qtchart
library itself. I also run the qt examples on my target platform by putting
resulting `libQtCharts.so` and other files manually in `/usr/lib/` and
`/usr/include/` on the target and I was able to draw the charts on target.

However, what I need is to include the charts in my project and run `qmake`
steps as mentioned above. But what I get is the `Project ERROR:  Unknown
module(s) in QT: charts`
I have tried to put `libQtCharts.so` which I got from compiling qt source
manually in 
`/opt/myimage/2.1.2/sysroots/cortexa9hf-neon-poky-linux-gnueabi/usr/lib`
but still not able to get the make file with `qmake -o Makefile
areachart.pro`

Regards,
Pehen
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Generating Yocto SDK as .deb (Debian) pacakge

2018-01-31 Thread Khem Raj

On Wed, Jan 31, 2018 at 4:31 AM, Zoran Stojsavljevic
 wrote:
> I'll add here another list, since these people might be interested in
> this thread/topic.
>

thats a fine idea you might want to look into

http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.1/toolchain/

for prebuilt SDKs

> Best Regards,
> Zoran
> ___
>
> On Wed, Jan 31, 2018 at 9:05 AM, Gaurang Shastri  wrote:
>> Hi Team,
>>
>> How can I generate Yocto generated SDK as .deb package? Currently it is in
>> the form of installable shell script but I want to generate it as .deb
>> package so that I can directly install it on my Ubuntu VM using "apt-get"
>> command.
>>
>> Is this supported? Any documentation?
>>
>> Regards,
>> Gaurang
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Generating Yocto SDK as .deb (Debian) pacakge

2018-01-31 Thread Zoran Stojsavljevic

I'll add here another list, since these people might be interested in
this thread/topic.

Best Regards,
Zoran
___

On Wed, Jan 31, 2018 at 9:05 AM, Gaurang Shastri  wrote:
> Hi Team,
>
> How can I generate Yocto generated SDK as .deb package? Currently it is in
> the form of installable shell script but I want to generate it as .deb
> package so that I can directly install it on my Ubuntu VM using "apt-get"
> command.
>
> Is this supported? Any documentation?
>
> Regards,
> Gaurang
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Generating Yocto SDK as .deb (Debian) pacakge

2018-01-31 Thread Burton, Ross

There's no support for this, but it should be fairly simple to write a
debian/rules yourself to package the SDK in a deb.

Ross

On 31 January 2018 at 08:05, Gaurang Shastri  wrote:

> Hi Team,
>
> How can I generate Yocto generated SDK as .deb package? Currently it is in
> the form of installable shell script but I want to generate it as .deb
> package so that I can directly install it on my Ubuntu VM using "apt-get"
> command.
>
> Is this supported? Any documentation?
>
> Regards,
> Gaurang
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Generating Yocto SDK as .deb (Debian) pacakge

2018-01-31 Thread Gaurang Shastri

Hi Team,

How can I generate Yocto generated SDK as .deb package? Currently it is in
the form of installable shell script but I want to generate it as .deb
package so that I can directly install it on my Ubuntu VM using "apt-get"
command.

Is this supported? Any documentation?

Regards,
Gaurang
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto SDK: how to rebuild *.dtb? (fatal error: dt-bindings/gpio/gpio.h: No such file or directory)

2018-01-15 Thread Jerry Lian

I installed yocto SDK for my beaglebone black.
But when I try to rebuild am335x-boneblack.dtb, I got error:

"arch/arm/boot/dts/am33xx.dtsi:11:10: fatal error:
dt-bindings/gpio/gpio.h: No such file or directory"

Any hint? Thanks!

Jerry
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto SDK: how to deploy application with step "make install" to target?

2017-12-04 Thread Jerry Lian

Thanks Philip!
I will try "sshfs" later. Right now using copy (via scp) works fine for
both "make install" and "make modules_install", and my application runs.





On Sun, Dec 3, 2017 at 9:17 AM, Philip Balister  wrote:

> On 12/01/2017 10:15 AM, Jerry Lian wrote:
> > Thanks Eric for your explanation!
> > * (I know I can build the app within yocto build, but sometimes I prefer
> > the SDK method outside yocto build.)
> > * So just copy manually? I thought there are some tricks  that I don't
> know.
> >
> > Now I have follow-up question:
> > * It seems that "make install" will copy different files to different
> > folders
> > * Can I do like these:?
> > --- make
> > --- copy (via scp)
> > --- make install
> > * Or it needs to be:
> > --- make
> > --- make install
> > --- copy (via scp) -then how do I know: what files to go which
> folder?
> > --- can you explain:
> > "... you may supply a custom install prefix directory to configure."
> > --- how?
>
> I've used sshfs to mount the target on the machine with the sdk and then
> something like:
>
> make install DESTDIR=~/mydevice
>
> From:
>
> https://wiki.gnuradio.org/index.php/Cross_compile_an_
> OOT_and_install_on_target
>
> Philip
>
> >
> > Thanks!
> >
> >
> >
> >
> >
> > On Fri, Dec 1, 2017 at 9:34 AM, Eric Schwarz 
> > wrote:
> >
> >> Am 01.12.2017 15:16, schrieb Eric Schwarz:
> >>
> >> Hi Jerry,
> >>>
> >>> Am 01.12.2017 15:07, schrieb Jerry Lian:
> >>>
> >>> I am new to embedded linux, and some concepts confuse me:
> >>>> * I have downloaded an Autotools-based application to run on my board.
> >>>> * If I boot the board with original image/original SDK, I normally
> >>>> build/install it with steps:
> >>>> - ./bootstrap
> >>>> - ./configure
> >>>> - make
> >>>> - make install
> >>>>
> >>>
> >>> You may build your app within yocto build process so your application
> is
> >>> contained in your rootFS directly.
> >>>
> >>> * Now if I boot the board with yocto image without SDK, how can I
> deploy
> >>>> the application?
> >>>>  (surely I do "bitbake -c populate_sdk some-image", and source the
> >>>> environment!)
> >>>>
> >>>> - ./bootstrap (Yocto SDK on host)
> >>>> - ./configure (Yocto SDK on host)
> >>>> - make (Yocto SDK on host)
> >>>> - make install (???)
> >>>>
> >>>
> >>> If you build it w/ the SDK outside of the yocto build process just
> >>> install it to a local directory and copy all the stuff w/ e.g. scp onto
> >>> your boards rootFS.
> >>>
> >>
> >> ... you may supply a custom install prefix directory to configure.
> >>
> >>
> >>
> >>> * How to do "make install"? (I want to install it on target, but how?)
> >>>>
> >>>> Thanks!
> >>>>
> >>>
> >>> Cheers
> >>> Eric
> >>>
> >>
> >
> >
> >
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto SDK: how to deploy application with step "make install" to target?

2017-12-03 Thread Philip Balister

On 12/01/2017 10:15 AM, Jerry Lian wrote:
> Thanks Eric for your explanation!
> * (I know I can build the app within yocto build, but sometimes I prefer
> the SDK method outside yocto build.)
> * So just copy manually? I thought there are some tricks  that I don't know.
> 
> Now I have follow-up question:
> * It seems that "make install" will copy different files to different
> folders
> * Can I do like these:?
> --- make
> --- copy (via scp)
> --- make install
> * Or it needs to be:
> --- make
> --- make install
> --- copy (via scp) -then how do I know: what files to go which folder?
> --- can you explain:
> "... you may supply a custom install prefix directory to configure."
> --- how?

I've used sshfs to mount the target on the machine with the sdk and then
something like:

make install DESTDIR=~/mydevice

From:

https://wiki.gnuradio.org/index.php/Cross_compile_an_OOT_and_install_on_target

Philip

> 
> Thanks!
> 
> 
> 
> 
> 
> On Fri, Dec 1, 2017 at 9:34 AM, Eric Schwarz 
> wrote:
> 
>> Am 01.12.2017 15:16, schrieb Eric Schwarz:
>>
>> Hi Jerry,
>>>
>>> Am 01.12.2017 15:07, schrieb Jerry Lian:
>>>
>>> I am new to embedded linux, and some concepts confuse me:
>>>> * I have downloaded an Autotools-based application to run on my board.
>>>> * If I boot the board with original image/original SDK, I normally
>>>> build/install it with steps:
>>>> - ./bootstrap
>>>> - ./configure
>>>> - make
>>>> - make install
>>>>
>>>
>>> You may build your app within yocto build process so your application is
>>> contained in your rootFS directly.
>>>
>>> * Now if I boot the board with yocto image without SDK, how can I deploy
>>>> the application?
>>>>  (surely I do "bitbake -c populate_sdk some-image", and source the
>>>> environment!)
>>>>
>>>> - ./bootstrap (Yocto SDK on host)
>>>> - ./configure (Yocto SDK on host)
>>>> - make (Yocto SDK on host)
>>>> - make install (???)
>>>>
>>>
>>> If you build it w/ the SDK outside of the yocto build process just
>>> install it to a local directory and copy all the stuff w/ e.g. scp onto
>>> your boards rootFS.
>>>
>>
>> ... you may supply a custom install prefix directory to configure.
>>
>>
>>
>>> * How to do "make install"? (I want to install it on target, but how?)
>>>>
>>>> Thanks!
>>>>
>>>
>>> Cheers
>>> Eric
>>>
>>
> 
> 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto SDK: how to deploy application with step "make install" to target?

2017-12-01 Thread Jerry Lian

; --- copy (via scp)
>> --- make install
>> * Or it needs to be:
>> --- make
>> --- make install Install the cross-compiled stuff on your local disc e.g.
>> into a "transfer" directory. Then copy it to the target.
>> On the target 'cp -Rfa /* /' should do it if the basic
>> directory structure fits to your rootFS.
>>
>> --- copy (via scp) -then how do I know: what files to go which folder?
>> --- can you explain:
>> "... you may supply a custom install prefix directory to configure." ---
>> how?
>>
>> There is IMHO no standardized variable available. Just look into the
>> configure script how the variable is named and if it is actually available
>> at all.
>>
>> Thanks!
>>
>> On Fri, Dec 1, 2017 at 9:34 AM, Eric Schwarz 
>> wrote:
>> Am 01.12.2017 15:16, schrieb Eric Schwarz:
>>
>> Hi Jerry,
>>
>> Am 01.12.2017 15:07, schrieb Jerry Lian:
>>
>> I am new to embedded linux, and some concepts confuse me:
>> * I have downloaded an Autotools-based application to run on my board.
>> * If I boot the board with original image/original SDK, I normally
>> build/install it with steps:
>> - ./bootstrap
>> - ./configure
>> - make
>> - make install
>> You may build your app within yocto build process so your application is
>> contained in your rootFS directly.
>>
>> * Now if I boot the board with yocto image without SDK, how can I deploy
>> the application?
>>  (surely I do "bitbake -c populate_sdk some-image", and source the
>> environment!)
>>
>> - ./bootstrap (Yocto SDK on host)
>> - ./configure (Yocto SDK on host)
>> - make (Yocto SDK on host)
>> - make install (???)
>> If you build it w/ the SDK outside of the yocto build process just
>> install it to a local directory and copy all the stuff w/ e.g. scp onto
>> your boards rootFS.  ... you may supply a custom install prefix directory
>> to configure.
>>
>> * How to do "make install"? (I want to install it on target, but how?)
>>
>> Thanks!
>> Cheers
>> Eric
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto SDK: how to deploy application with step "make install" to target?

2017-12-01 Thread Eric Schwarz


Am 01.12.2017 16:58, schrieb Jerry Lian:


Thanks Eric again.
* So you mean "copy -Rfa" can match folder-by-folder, so long as the 
folder-tree are the same?

(if yes, that is super great!!!)


Yes.

* I check that "make install" copy files to one folder, so that is easy 
for deployment!


Another question:
* My application actually has another step: "make modules_install" 
(surely step "make modules" also)

* But I got error (see below):
what could be wrong with "SSL error"? isn't build already passed 
successfully?


You are doing the 'make modules_install' on the target or where else? 
You need to build the modules within the Yocto environment and may 
create a package e.g. *.deb you may install later on the target or copy 
the modules by hand including relevant other files needed. Obviously the 
system tries to recompile the kernel modules. That's what 'make 
modules_install' does.





jerry@yct:~/ecat-33b922$ make modules_install
make -C "/usr/src/linux-headers-4.10.0-28-generic" 
M="/home/jerry/ecat-33b922" \

INSTALL_MOD_DIR="ethercat" modules_install
make[1]: Entering directory '/usr/src/linux-headers-4.10.0-28-generic'
mkdir: cannot create directory 
'/lib/modules/4.10.0-28-generic/ethercat': Permission denied

Makefile:1536: recipe for target '_emodinst_' failed
make[1]: *** [_emodinst_] Error 1
make[1]: Leaving directory '/usr/src/linux-headers-4.10.0-28-generic'
Makefile:934: recipe for target 'modules_install' failed
make: *** [modules_install] Error 2

jerry@yct:~/ecat-33b922$ sudo make modules_install
make -C "/usr/src/linux-headers-4.10.0-28-generic" 
M="/home/jerry/ecat-33b922" \

INSTALL_MOD_DIR="ethercat" modules_install
make[1]: Entering directory '/usr/src/linux-headers-4.10.0-28-generic'
INSTALL /home/jerry/ecat-33b922/devices/ec_generic.ko
At main.c:158:
- SSL error:02001002:system library:fopen:No such file or directory: 
bss_file.c:175
- SSL error:2006D080:BIO routines:BIO_new_file:no such file: 
bss_file.c:178

sign-file: certs/signing_key.pem: No such file or directory
INSTALL /home/jerry/ecat-33b922/examples/mini/ec_mini.ko
At main.c:158:
- SSL error:02001002:system library:fopen:No such file or directory: 
bss_file.c:175
- SSL error:2006D080:BIO routines:BIO_new_file:no such file: 
bss_file.c:178

sign-file: certs/signing_key.pem: No such file or directory
INSTALL /home/jerry/ecat-33b922/master/ec_master.ko
At main.c:158:
- SSL error:02001002:system library:fopen:No such file or directory: 
bss_file.c:175
- SSL error:2006D080:BIO routines:BIO_new_file:no such file: 
bss_file.c:178

sign-file: certs/signing_key.pem: No such file or directory
DEPMOD  4.10.0-28-generic
make[1]: Leaving directory '/usr/src/linux-headers-4.10.0-28-generic'

jerry@yct:~/ecat-33b922$
---

Thanks!

On Fri, Dec 1, 2017 at 10:37 AM, Eric Schwarz  
wrote:

Am 01.12.2017 16:15, schrieb Jerry Lian:

Thanks Eric for your explanation!
* (I know I can build the app within yocto build, but sometimes I 
prefer the SDK method outside yocto build.)


* So just copy manually? I thought there are some tricks  that I don't 
know.


Acutally that's how we are doing it ...

Now I have follow-up question:
* It seems that "make install" will copy different files to different 
folders

* Can I do like these:?
--- make
--- copy (via scp)
--- make install
* Or it needs to be:
--- make
--- make install Install the cross-compiled stuff on your local disc 
e.g. into a "transfer" directory. Then copy it to the target.
On the target 'cp -Rfa /* /' should do it if the basic 
directory structure fits to your rootFS.


--- copy (via scp) -then how do I know: what files to go which 
folder?

--- can you explain:
"... you may supply a custom install prefix directory to configure." 
--- how?


There is IMHO no standardized variable available. Just look into the 
configure script how the variable is named and if it is actually 
available at all.


Thanks!

On Fri, Dec 1, 2017 at 9:34 AM, Eric Schwarz  
wrote:

Am 01.12.2017 15:16, schrieb Eric Schwarz:

Hi Jerry,

Am 01.12.2017 15:07, schrieb Jerry Lian:

I am new to embedded linux, and some concepts confuse me:
* I have downloaded an Autotools-based application to run on my board.
* If I boot the board with original image/original SDK, I normally 
build/install it with steps:

- ./bootstrap
- ./configure
- make
- make install
You may build your app within yocto build process so your application 
is contained in your rootFS directly.


* Now if I boot the board with yocto image without SDK, how can I 
deploy th

Re: [yocto] Yocto SDK: how to deploy application with step "make install" to target?

2017-12-01 Thread Jerry Lian

Thanks Eric again.
* So you mean "copy -Rfa" can match folder-by-folder, so long as the
folder-tree are the same?
(if yes, that is super great!!!)
* I check that "make install" copy files to one folder, so that is easy for
deployment!

Another question:
* My application actually has another step: "make modules_install" (surely
step "make modules" also)
* But I got error (see below):
   what could be wrong with "SSL error"? isn't build already
passed successfully?



jerry@yct:~/ecat-33b922$ make modules_install
make -C "/usr/src/linux-headers-4.10.0-28-generic"
M="/home/jerry/ecat-33b922" \
INSTALL_MOD_DIR="ethercat" modules_install
make[1]: Entering directory '/usr/src/linux-headers-4.10.0-28-generic'
mkdir: cannot create directory ‘/lib/modules/4.10.0-28-generic/ethercat’:
Permission denied
Makefile:1536: recipe for target '_emodinst_' failed
make[1]: *** [_emodinst_] Error 1
make[1]: Leaving directory '/usr/src/linux-headers-4.10.0-28-generic'
Makefile:934: recipe for target 'modules_install' failed
make: *** [modules_install] Error 2

jerry@yct:~/ecat-33b922$ sudo make modules_install
make -C "/usr/src/linux-headers-4.10.0-28-generic"
M="/home/jerry/ecat-33b922" \
INSTALL_MOD_DIR="ethercat" modules_install
make[1]: Entering directory '/usr/src/linux-headers-4.10.0-28-generic'
  INSTALL /home/jerry/ecat-33b922/devices/ec_generic.ko
At main.c:158:
- SSL error:02001002:system library:fopen:No such file or directory:
bss_file.c:175
- SSL error:2006D080:BIO routines:BIO_new_file:no such file: bss_file.c:178
sign-file: certs/signing_key.pem: No such file or directory
  INSTALL /home/jerry/ecat-33b922/examples/mini/ec_mini.ko
At main.c:158:
- SSL error:02001002:system library:fopen:No such file or directory:
bss_file.c:175
- SSL error:2006D080:BIO routines:BIO_new_file:no such file: bss_file.c:178
sign-file: certs/signing_key.pem: No such file or directory
  INSTALL /home/jerry/ecat-33b922/master/ec_master.ko
At main.c:158:
- SSL error:02001002:system library:fopen:No such file or directory:
bss_file.c:175
- SSL error:2006D080:BIO routines:BIO_new_file:no such file: bss_file.c:178
sign-file: certs/signing_key.pem: No such file or directory
  DEPMOD  4.10.0-28-generic
make[1]: Leaving directory '/usr/src/linux-headers-4.10.0-28-generic'

jerry@yct:~/ecat-33b922$

---

Thanks!






On Fri, Dec 1, 2017 at 10:37 AM, Eric Schwarz 
wrote:

> Am 01.12.2017 16:15, schrieb Jerry Lian:
>
> Thanks Eric for your explanation!
>> * (I know I can build the app within yocto build, but sometimes I prefer
>> the SDK method outside yocto build.)
>>
>> * So just copy manually? I thought there are some tricks  that I don't
>> know.
>>
>>
> Acutally that's how we are doing it ...
>
> Now I have follow-up question:
>> * It seems that "make install" will copy different files to different
>> folders
>> * Can I do like these:?
>> --- make
>> --- copy (via scp)
>> --- make install
>> * Or it needs to be:
>> --- make
>> --- make install
>>
>
> Install the cross-compiled stuff on your local disc e.g. into a "transfer"
> directory. Then copy it to the target.
> On the target 'cp -Rfa /* /' should do it if the basic
> directory structure fits to your rootFS.
>
> --- copy (via scp) -then how do I know: what files to go which folder?
>> --- can you explain:
>> "... you may supply a custom install prefix directory to configure." ---
>> how?
>>
>>
> There is IMHO no standardized variable available. Just look into the
> configure script how the variable is named and if it is actually available
> at all.
>
>
> Thanks!
>>
>> On Fri, Dec 1, 2017 at 9:34 AM, Eric Schwarz 
>> wrote:
>> Am 01.12.2017 15:16, schrieb Eric Schwarz:
>>
>> Hi Jerry,
>>
>> Am 01.12.2017 15:07, schrieb Jerry Lian:
>>
>> I am new to embedded linux, and some concepts confuse me:
>> * I have downloaded an Autotools-based application to run on my board.
>> * If I boot the board with original image/original SDK, I normally
>> build/install it with steps:
>> - ./bootstrap
>> - ./configure
>> - make
>> - make install
>> You may build your app within yocto build process so your application is
>> contained in your rootFS directly.
>>
>> * Now if I boot the board with yocto image without SDK, how c

Re: [yocto] Yocto SDK: how to deploy application with step "make install" to target?

2017-12-01 Thread Eric Schwarz


Am 01.12.2017 16:15, schrieb Jerry Lian:


Thanks Eric for your explanation!
* (I know I can build the app within yocto build, but sometimes I 
prefer the SDK method outside yocto build.)


* So just copy manually? I thought there are some tricks  that I don't 
know.




Acutally that's how we are doing it ...


Now I have follow-up question:
* It seems that "make install" will copy different files to different 
folders

* Can I do like these:?
--- make
--- copy (via scp)
--- make install
* Or it needs to be:
--- make
--- make install


Install the cross-compiled stuff on your local disc e.g. into a 
"transfer" directory. Then copy it to the target.
On the target 'cp -Rfa /* /' should do it if the basic 
directory structure fits to your rootFS.


--- copy (via scp) -then how do I know: what files to go which 
folder?

--- can you explain:
"... you may supply a custom install prefix directory to configure." 
--- how?




There is IMHO no standardized variable available. Just look into the 
configure script how the variable is named and if it is actually 
available at all.



Thanks!

On Fri, Dec 1, 2017 at 9:34 AM, Eric Schwarz  
wrote:

Am 01.12.2017 15:16, schrieb Eric Schwarz:

Hi Jerry,

Am 01.12.2017 15:07, schrieb Jerry Lian:

I am new to embedded linux, and some concepts confuse me:
* I have downloaded an Autotools-based application to run on my board.
* If I boot the board with original image/original SDK, I normally 
build/install it with steps:

- ./bootstrap
- ./configure
- make
- make install
You may build your app within yocto build process so your application 
is contained in your rootFS directly.


* Now if I boot the board with yocto image without SDK, how can I 
deploy the application?
 (surely I do "bitbake -c populate_sdk some-image", and source the 
environment!)


----- ./bootstrap (Yocto SDK on host)
----- ./configure (Yocto SDK on host)
- make (Yocto SDK on host)
- make install (???)
If you build it w/ the SDK outside of the yocto build process just 
install it to a local directory and copy all the stuff w/ e.g. scp onto 
your boards rootFS.

 ... you may supply a custom install prefix directory to configure.


* How to do "make install"? (I want to install it on target, but how?)

Thanks!


Cheers
Eric

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto SDK: how to deploy application with step "make install" to target?

2017-12-01 Thread Jerry Lian

Thanks Eric for your explanation!
* (I know I can build the app within yocto build, but sometimes I prefer
the SDK method outside yocto build.)
* So just copy manually? I thought there are some tricks  that I don't know.

Now I have follow-up question:
* It seems that "make install" will copy different files to different
folders
* Can I do like these:?
--- make
--- copy (via scp)
--- make install
* Or it needs to be:
--- make
--- make install
--- copy (via scp) -then how do I know: what files to go which folder?
--- can you explain:
"... you may supply a custom install prefix directory to configure."
--- how?

Thanks!





On Fri, Dec 1, 2017 at 9:34 AM, Eric Schwarz 
wrote:

> Am 01.12.2017 15:16, schrieb Eric Schwarz:
>
> Hi Jerry,
>>
>> Am 01.12.2017 15:07, schrieb Jerry Lian:
>>
>> I am new to embedded linux, and some concepts confuse me:
>>> * I have downloaded an Autotools-based application to run on my board.
>>> * If I boot the board with original image/original SDK, I normally
>>> build/install it with steps:
>>> - ./bootstrap
>>> - ./configure
>>> - make
>>> - make install
>>>
>>
>> You may build your app within yocto build process so your application is
>> contained in your rootFS directly.
>>
>> * Now if I boot the board with yocto image without SDK, how can I deploy
>>> the application?
>>>  (surely I do "bitbake -c populate_sdk some-image", and source the
>>> environment!)
>>>
>>> - ./bootstrap (Yocto SDK on host)
>>> - ./configure (Yocto SDK on host)
>>> - make (Yocto SDK on host)
>>> - make install (???)
>>>
>>
>> If you build it w/ the SDK outside of the yocto build process just
>> install it to a local directory and copy all the stuff w/ e.g. scp onto
>> your boards rootFS.
>>
>
> ... you may supply a custom install prefix directory to configure.
>
>
>
>> * How to do "make install"? (I want to install it on target, but how?)
>>>
>>> Thanks!
>>>
>>
>> Cheers
>> Eric
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto SDK: how to deploy application with step "make install" to target?

2017-12-01 Thread Eric Schwarz


Am 01.12.2017 15:16, schrieb Eric Schwarz:


Hi Jerry,

Am 01.12.2017 15:07, schrieb Jerry Lian:


I am new to embedded linux, and some concepts confuse me:
* I have downloaded an Autotools-based application to run on my board.
* If I boot the board with original image/original SDK, I normally 
build/install it with steps:

- ./bootstrap
- ./configure
- make
- make install


You may build your app within yocto build process so your application 
is contained in your rootFS directly.


* Now if I boot the board with yocto image without SDK, how can I 
deploy the application?
 (surely I do "bitbake -c populate_sdk some-image", and source the 
environment!)


- ./bootstrap (Yocto SDK on host)
- ./configure (Yocto SDK on host)
- make     (Yocto SDK on host)
- make install (???)


If you build it w/ the SDK outside of the yocto build process just 
install it to a local directory and copy all the stuff w/ e.g. scp onto 
your boards rootFS.


... you may supply a custom install prefix directory to configure.




* How to do "make install"? (I want to install it on target, but how?)

Thanks!


Cheers
Eric

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto SDK: how to deploy application with step "make install" to target?

2017-12-01 Thread Eric Schwarz


Hi Jerry,

Am 01.12.2017 15:07, schrieb Jerry Lian:


I am new to embedded linux, and some concepts confuse me:
* I have downloaded an Autotools-based application to run on my board.
* If I boot the board with original image/original SDK, I normally 
build/install it with steps:

- ./bootstrap
- ./configure
- make
- make install


You may build your app within yocto build process so your application is 
contained in your rootFS directly.


* Now if I boot the board with yocto image without SDK, how can I 
deploy the application?
 (surely I do "bitbake -c populate_sdk some-image", and source the 
environment!)


- ./bootstrap (Yocto SDK on host)
- ./configure (Yocto SDK on host)
- make     (Yocto SDK on host)
- make install (???)


If you build it w/ the SDK outside of the yocto build process just 
install it to a local directory and copy all the stuff w/ e.g. scp onto 
your boards rootFS.



* How to do "make install"? (I want to install it on target, but how?)

Thanks!


Cheers
Eric
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto SDK: how to deploy application with step "make install" to target?

2017-12-01 Thread Jerry Lian

I am new to embedded linux, and some concepts confuse me:
* I have downloaded an Autotools-based application to run on my board.
* If I boot the board with original image/original SDK, I normally
build/install it with steps:
- ./bootstrap
- ./configure
- make
- make install
* Now if I boot the board with yocto image without SDK, how can I deploy
the application?
 (surely I do "bitbake -c populate_sdk some-image", and source the
environment!)
- ./bootstrap (Yocto SDK on host)
- ./configure (Yocto SDK on host)
- make     (Yocto SDK on host)
- make install (???)

* How to do "make install"? (I want to install it on target, but how?)

Thanks!
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Concept clarification: can we deploy Yocto SDK to target?

2017-11-30 Thread Jerry Lian

Thanks Paul for your expert explanation, though I may not fully understand
yet.
Here is my scenario when raising my question:
* After deploying yocto image to hardware-target, I try build an
application (Autotools-based)
* The build stopped and asked for linux kernel source.

* So my image already contains compilers and linkers?
* So am I missing libraries, or just linux-headers?
* what is difference between libraries and headers?

Thanks!








On Wed, Nov 29, 2017 at 6:03 PM, Paul Eggleton <
paul.eggle...@linux.intel.com> wrote:

> Hi Jerry,
>
> On Thursday, 30 November 2017 10:35:32 AM NZDT Jerry Lian wrote:
> > I am confused about the concept of Yocto SDK:
> > * when we use "bitbake -c populate_sdk some_image", we obtain sysroots
> for
> > both target and host.
> > * But why do we need sysroot for host?
>
> The host sysroot actually contains the main part of the SDK - the cross-
> compiler and other tools that need to run on the host. The target part
> usually
> doesn't include any executable binaries, only libraries and debugging
> symbols.
>
> > * I know we can build application under target-sysroot (surely source the
> > environment), with fast speed.
> > * But can we deploy target-sysroot to hardware-target?
> > (Yes, I do want to compile/build application inside hardware-target, even
> > though it is slow)
>
> I would suggest an alternative - install the compiler and tools into your
> image. You could do this when building the image, or alternatively if you
> enable package management in the image you could install them after the
> fact.
> At the image level there's a "tools-sdk" IMAGE_FEATURES item that will
> install
> the appropriate packages; alternatively you can install
> packagegroup-core-sdk
> which is effectively the same thing or for something a little more
> lightweight
> there is packagegroup-core-buildessential (roughly equivalent to debian's
> build-essential).
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Concept clarification: can we deploy Yocto SDK to target?

2017-11-29 Thread Paul Eggleton

Hi Jerry,

On Thursday, 30 November 2017 10:35:32 AM NZDT Jerry Lian wrote:
> I am confused about the concept of Yocto SDK:
> * when we use "bitbake -c populate_sdk some_image", we obtain sysroots for
> both target and host.
> * But why do we need sysroot for host?

The host sysroot actually contains the main part of the SDK - the cross-
compiler and other tools that need to run on the host. The target part usually 
doesn't include any executable binaries, only libraries and debugging symbols.

> * I know we can build application under target-sysroot (surely source the
> environment), with fast speed.
> * But can we deploy target-sysroot to hardware-target?
> (Yes, I do want to compile/build application inside hardware-target, even
> though it is slow)

I would suggest an alternative - install the compiler and tools into your 
image. You could do this when building the image, or alternatively if you 
enable package management in the image you could install them after the fact. 
At the image level there's a "tools-sdk" IMAGE_FEATURES item that will install 
the appropriate packages; alternatively you can install packagegroup-core-sdk 
which is effectively the same thing or for something a little more lightweight 
there is packagegroup-core-buildessential (roughly equivalent to debian's 
build-essential).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Concept clarification: can we deploy Yocto SDK to target?

2017-11-29 Thread Jerry Lian

I am confused about the concept of Yocto SDK:
* when we use "bitbake -c populate_sdk some_image", we obtain sysroots for
both target and host.
* But why do we need sysroot for host?

* I know we can build application under target-sysroot (surely source the
environment), with fast speed.
* But can we deploy target-sysroot to hardware-target?
(Yes, I do want to compile/build application inside hardware-target, even
though it is slow)

Thanks!
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] SDK license manifest

2017-07-20 Thread Russell Peterson

Hello,

I am currently building an SDK and a disk image using morty.  Learning quite a 
bit about Yocto.

Eventually I will distribute both the SDK and the rootfs image to customers.  I 
see that there is a license manifest generated for the full rootfs which is 
very useful.  My question is, what about the SDK?  Is the SDK covered by the 
same manifest or is there something I’m missing.  I assume there are some 
things in the nativesdk rootfs, for example, that need to be tracked.

Thanks!

Russell

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK with enabled multilib conf, missing compilers

2017-01-09 Thread Schmitt, Richard

I believe you need to apply a patch that is already in the poky git tree but 
might not be in the branch you are on.  Try:

git fetch origin
git cherry-pick b6253350fb86d8e54792905342a5892af570d526

Rich

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Oleksy, Adam (Nokia - PL/Wroclaw)
Sent: Wednesday, January 04, 2017 2:52 AM
To: yocto@yoctoproject.org
Subject: [yocto] SDK with enabled multilib conf, missing compilers

Hi,
I'm int the process of enabling multlib configuration for my distro, by adding 
following lines to local.conf file:
# Define multilib target
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7athf-neon"

I'm able to produce images, where applications are 32 bits apps, and the system 
is 64 bits. However, I've faced problems with SDK... Neither 32bit nor 64bit 
application can be compiled.

I've produced SDK by typink: bitbake
After installing SDK, I get instruction how to source the SDK:
 $ . ~/sdk-multilib/environment-setup-aarch64-poky-linux
 $ . 
~/sdk-multilib/environment-setup-armv7ahf-vfp-neon-pokymllib32-linux-gnueabi

When I source environment-setup-armv7ahf-vfp-neon-pokymllib32-linux-gnueabi 
file, then the environment is set up, e.g.:
$ echo $CC
arm-pokymllib32-linux-gnueabi-gcc -march=armv7-a -marm -mthumb-interwork 
-mfloat-abi=hard -mfpu=neon --sysroot=~/sdk-multilib/sysroots/aarch64-poky-linux

however, arm-pokymllib32-linux-gnueabi-gcc compiler does not exists in the SDK:
$ find /home/oleksy/workspace/sdk-multilib/ -name 
arm-pokymllib32-linux-gnueabi-gcc | wc -l
0

It exists in directory structure, where SDK was built:
./tmp/sysroots/x86_64-linux/usr/bin/arm-pokymllib32-linux-gnueabi/arm-pokymllib32-linux-gnueabi-gcc

So, it seems that this compiler is built but not included into SDK installer. 
The question is: how to force putting this compiler into SDK?
I'm using poky jethro (I now there is newer version, but I have to use this) 
with meta-xilinx (https://github.com/Xilinx/meta-xilinx).

.
Best Regards,
Adam Oleksy

Nokia Solutions and Networks Sp. z o.o.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] SDK with enabled multilib conf, missing compilers

2017-01-09 Thread Oleksy, Adam (Nokia - PL/Wroclaw)

Hi,
I'm int the process of enabling multlib configuration for my distro, by adding 
following lines to local.conf file:
# Define multilib target
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7athf-neon"

I'm able to produce images, where applications are 32 bits apps, and the system 
is 64 bits. However, I've faced problems with SDK... Neither 32bit nor 64bit 
application can be compiled.

I've produced SDK by typink: bitbake
After installing SDK, I get instruction how to source the SDK:
 $ . ~/sdk-multilib/environment-setup-aarch64-poky-linux
 $ . 
~/sdk-multilib/environment-setup-armv7ahf-vfp-neon-pokymllib32-linux-gnueabi

When I source environment-setup-armv7ahf-vfp-neon-pokymllib32-linux-gnueabi 
file, then the environment is set up, e.g.:
$ echo $CC
arm-pokymllib32-linux-gnueabi-gcc -march=armv7-a -marm -mthumb-interwork 
-mfloat-abi=hard -mfpu=neon --sysroot=~/sdk-multilib/sysroots/aarch64-poky-linux

however, arm-pokymllib32-linux-gnueabi-gcc compiler does not exists in the SDK:
$ find /home/oleksy/workspace/sdk-multilib/ -name 
arm-pokymllib32-linux-gnueabi-gcc | wc -l
0

It exists in directory structure, where SDK was built:
./tmp/sysroots/x86_64-linux/usr/bin/arm-pokymllib32-linux-gnueabi/arm-pokymllib32-linux-gnueabi-gcc

So, it seems that this compiler is built but not included into SDK installer. 
The question is: how to force putting this compiler into SDK?
I'm using poky jethro (I now there is newer version, but I have to use this) 
with meta-xilinx (https://github.com/Xilinx/meta-xilinx).

.
Best Regards,
Adam Oleksy

Nokia Solutions and Networks Sp. z o.o.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK: Missing 32 bit sysroot

2017-01-04 Thread Khem Raj

On Wed, Jan 4, 2017 at 6:35 AM, Schmitt, Richard
 wrote:
> I have a ARM 32/64 multilib environment set up in my yocto based project.
> Everythings working fine.  Almost.  I am using the poky krogoth branch with
> the patch for “bug 1357”
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1357 cherry-picked.
>
>
>
> When I populate the SDK and install it, I do get two toolchains with the
> correct multilibs and the correct environment setup files
>
>
>
> The two environment setup files are:
>
>
>
> environment-setup-aarch32hf-neon-fp-armv8-pokymllib32-linux-gnueabi
>
> environment-setup-aarch64-poky-linux
>
>
>
> The two respective toolchains are:
>
>
>
> arm-pokymllib32-linux-gnueabi-
>
> aarch64-poky-linux-
>
>
>
> Both of these toolchains are set up to use the 64 bit arm sysroot:
>
>
>
> /opt/poky/2.1.2/sysroots/aarch64-poky-linux
>
>
>
> There is one small issue.  The ARM sysroot that is exported contains linux
> include files that can only be used by the 64 bit toolchain.  For example:
>
>
>
> Within the aarch64 sysroot, the linux include file:
>
>
>
> /opt/poky/2.1.2/sysroots/aarch64-poky-linux/usr/include/asm/sigcontext.h
>
>
>
> Contains the implicit type __uint128_t.  This type is not defined when using
> the arm-pokymllib32-linux-gnueabi- toolchain so any 32 bit that includes
>  will fail to compile.


__uint128_t is implicit type defined by gcc internally on certain
architectures which can support 128bit int.
however this does mean that the headers which are assuming this to be
available should be made multilib
so you might need to use oe_multilib_header to install multilib
specific versions of the file which is asking
for this type.

>
>
>
> In my yocto build directory, I have a target sysroot for both the 32 bit and
> 64 bit environments:
>
>
>
> tmp/sysroot/lib32-machine
>
> tmp/sysroot/machine
>
>
>
> where machine is the value of the MACHINE define.
>
>
>
> These two sysroots contain different usr/include/asm/sigcontext.h files.
>
>
>
> If I copy over the lib32-machine sysroot to the opt/poky/sysroots directory
> and use that sysroot when compiling 32 bit apps, things appear to work.
>
>
>
> Now I am not quite sure the right way to fix this.  There are at least three
> possibilities:
>
>
>
> 1.   The 32 bit toolchain should be able to understand __uint128_t even
> if it interprets to an array blob
>
> 2.   Yocto populate_sdk should export the 32 and 64 bit sysroots
>
> 3.   glibc should create include files that are useable in both 32 and
> 64 bit environments.
>
>
>
> What are folks thoughts here?  Right now I’m manually doing #2.
>
>
>
> Thanks,
>
> Rich
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] SDK: Missing 32 bit sysroot

2017-01-04 Thread Schmitt, Richard

I have a ARM 32/64 multilib environment set up in my yocto based project.  
Everythings working fine.  Almost.  I am using the poky krogoth branch with the 
patch for "bug 1357" https://bugzilla.yoctoproject.org/show_bug.cgi?id=1357 
cherry-picked.

When I populate the SDK and install it, I do get two toolchains with the 
correct multilibs and the correct environment setup files

The two environment setup files are:

environment-setup-aarch32hf-neon-fp-armv8-pokymllib32-linux-gnueabi
environment-setup-aarch64-poky-linux

The two respective toolchains are:

arm-pokymllib32-linux-gnueabi-
aarch64-poky-linux-

Both of these toolchains are set up to use the 64 bit arm sysroot:

/opt/poky/2.1.2/sysroots/aarch64-poky-linux

There is one small issue.  The ARM sysroot that is exported contains linux 
include files that can only be used by the 64 bit toolchain.  For example:

Within the aarch64 sysroot, the linux include file:

/opt/poky/2.1.2/sysroots/aarch64-poky-linux/usr/include/asm/sigcontext.h

Contains the implicit type __uint128_t.  This type is not defined when using 
the arm-pokymllib32-linux-gnueabi- toolchain so any 32 bit that includes 
 will fail to compile.

In my yocto build directory, I have a target sysroot for both the 32 bit and 64 
bit environments:

tmp/sysroot/lib32-machine
tmp/sysroot/machine

where machine is the value of the MACHINE define.

These two sysroots contain different usr/include/asm/sigcontext.h files.

If I copy over the lib32-machine sysroot to the opt/poky/sysroots directory and 
use that sysroot when compiling 32 bit apps, things appear to work.

Now I am not quite sure the right way to fix this.  There are at least three 
possibilities:


1.   The 32 bit toolchain should be able to understand __uint128_t even if 
it interprets to an array blob

2.   Yocto populate_sdk should export the 32 and 64 bit sysroots

3.   glibc should create include files that are useable in both 32 and 64 
bit environments.

What are folks thoughts here?  Right now I'm manually doing #2.

Thanks,
Rich
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK manual is not listed on docs page

2016-10-22 Thread Khem Raj


> On Oct 22, 2016, at 9:32 AM, Robert P. J. Day  wrote:
> 
> 
>  i don't see link to SDK manual here:
> 
> https://www.yoctoproject.org/documentation/inprogress
> 
> is that deliberate, or an oversight?

file a documentation ticket.

> 
> rday
> 
> --
> 
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
>http://crashcourse.ca
> 
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] SDK manual is not listed on docs page

2016-10-22 Thread Robert P. J. Day


  i don't see link to SDK manual here:

https://www.yoctoproject.org/documentation/inprogress

is that deliberate, or an oversight?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK Problems for SuperH 4

2016-10-07 Thread Khem Raj


> On Oct 7, 2016, at 12:58 AM, Martin Townsend  wrote:
> 
> On Fri, Oct 7, 2016 at 8:46 AM, Martin Townsend  
> wrote:
>> On Fri, Oct 7, 2016 at 5:32 AM, Khem Raj  wrote:
>>> 
 On Oct 6, 2016, at 12:09 PM, Martin Townsend  
 wrote:
 
 On Thu, Oct 6, 2016 at 7:57 PM, Martin Townsend  
 wrote:
> Hi,
> 
> We have a poky sato distributions successfully built and running for
> our SuperH 4 processor board.  The problem is the SDK that is built
> when using -cpopulate_sdk doesn't.
> 
> The simple Makefile:
> hellomake: HelloWorld.c
> $(CC) -o HelloWorld HelloWorld.c
 
 Hit send before I had chance to finish :)
 
 ignore the missing tab but when trying to compile (after sourcing the
 SDK environment) I get
 sh4-poky-linux-gcc  -ml -m4
 --sysroot=/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux -o HelloWorld
 HelloWorld.o
 /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
 cannot find crt1.o: No such file or directory
 /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
 cannot find crti.o: No such file or directory
 /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
 cannot find crtbegin.o: No such file or directory
 /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
 cannot find -lgcc
 /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
 cannot find -lgcc_s
 /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
 cannot find -lc
 /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
 cannot find -lgcc
 /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
 cannot find -lgcc_s
 /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
 cannot find crtend.o: No such file or directory
 /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
 cannot find crtn.o: No such file or directory
 
 So I tried the compiler and sysroot from the build
 CC=/ws/vms/vms-rsc-yocto-build/build_vms/tmp/sysroots/x86_64-linux/usr/bin/sh4-poky-linux/sh4-poky-linux-gcc
 SYSROOT=/ws/vms/vms-rsc-yocto-build/build_vms/tmp/sysroots/sh7760
 
 hellomake: HelloWorld.c
 $(CC) --sysroot=$(SYSROOT) -o HelloWorld HelloWorld.c
 
 and it compiles fine.
 
 So I ran $CC -print-search-dirs
 install: 
 /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/
 programs: 
 =/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/bin/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/bin/
 libraries: 
 =/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/lib/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/lib/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/usr/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/usr/lib/
 
 Then I checked that these files exist:
 martin@martin-ubuntu-pconcepts:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux$
 find $SDKTARGETSYSROOT -name "crt*"
 /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crtn.o
 /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crti.o
 /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crt1.o
 /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtendS.o
 /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtend.o
 /opt/sdk/vms/2.0.2/sysroots/sh4-

Re: [yocto] SDK Problems for SuperH 4

2016-10-07 Thread Martin Townsend

On Fri, Oct 7, 2016 at 8:46 AM, Martin Townsend  wrote:
> On Fri, Oct 7, 2016 at 5:32 AM, Khem Raj  wrote:
>>
>>> On Oct 6, 2016, at 12:09 PM, Martin Townsend  
>>> wrote:
>>>
>>> On Thu, Oct 6, 2016 at 7:57 PM, Martin Townsend  
>>> wrote:
 Hi,

 We have a poky sato distributions successfully built and running for
 our SuperH 4 processor board.  The problem is the SDK that is built
 when using -cpopulate_sdk doesn't.

 The simple Makefile:
 hellomake: HelloWorld.c
 $(CC) -o HelloWorld HelloWorld.c
>>>
>>> Hit send before I had chance to finish :)
>>>
>>> ignore the missing tab but when trying to compile (after sourcing the
>>> SDK environment) I get
>>> sh4-poky-linux-gcc  -ml -m4
>>> --sysroot=/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux -o HelloWorld
>>> HelloWorld.o
>>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
>>> cannot find crt1.o: No such file or directory
>>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
>>> cannot find crti.o: No such file or directory
>>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
>>> cannot find crtbegin.o: No such file or directory
>>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
>>> cannot find -lgcc
>>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
>>> cannot find -lgcc_s
>>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
>>> cannot find -lc
>>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
>>> cannot find -lgcc
>>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
>>> cannot find -lgcc_s
>>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
>>> cannot find crtend.o: No such file or directory
>>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
>>> cannot find crtn.o: No such file or directory
>>>
>>> So I tried the compiler and sysroot from the build
>>> CC=/ws/vms/vms-rsc-yocto-build/build_vms/tmp/sysroots/x86_64-linux/usr/bin/sh4-poky-linux/sh4-poky-linux-gcc
>>> SYSROOT=/ws/vms/vms-rsc-yocto-build/build_vms/tmp/sysroots/sh7760
>>>
>>> hellomake: HelloWorld.c
>>> $(CC) --sysroot=$(SYSROOT) -o HelloWorld HelloWorld.c
>>>
>>> and it compiles fine.
>>>
>>> So I ran $CC -print-search-dirs
>>> install: 
>>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/
>>> programs: 
>>> =/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/bin/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/bin/
>>> libraries: 
>>> =/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/lib/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/lib/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/usr/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/usr/lib/
>>>
>>> Then I checked that these files exist:
>>> martin@martin-ubuntu-pconcepts:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux$
>>> find $SDKTARGETSYSROOT -name "crt*"
>>> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crtn.o
>>> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crti.o
>>> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crt1.o
>>> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtendS.o
>>> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtend.o
>>> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtbeginT.o
>>> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtbeginS.o
>>> /o

Re: [yocto] SDK Problems for SuperH 4

2016-10-07 Thread Martin Townsend

On Fri, Oct 7, 2016 at 5:32 AM, Khem Raj  wrote:
>
>> On Oct 6, 2016, at 12:09 PM, Martin Townsend  wrote:
>>
>> On Thu, Oct 6, 2016 at 7:57 PM, Martin Townsend  
>> wrote:
>>> Hi,
>>>
>>> We have a poky sato distributions successfully built and running for
>>> our SuperH 4 processor board.  The problem is the SDK that is built
>>> when using -cpopulate_sdk doesn't.
>>>
>>> The simple Makefile:
>>> hellomake: HelloWorld.c
>>> $(CC) -o HelloWorld HelloWorld.c
>>
>> Hit send before I had chance to finish :)
>>
>> ignore the missing tab but when trying to compile (after sourcing the
>> SDK environment) I get
>> sh4-poky-linux-gcc  -ml -m4
>> --sysroot=/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux -o HelloWorld
>> HelloWorld.o
>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
>> cannot find crt1.o: No such file or directory
>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
>> cannot find crti.o: No such file or directory
>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
>> cannot find crtbegin.o: No such file or directory
>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
>> cannot find -lgcc
>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
>> cannot find -lgcc_s
>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
>> cannot find -lc
>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
>> cannot find -lgcc
>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
>> cannot find -lgcc_s
>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
>> cannot find crtend.o: No such file or directory
>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
>> cannot find crtn.o: No such file or directory
>>
>> So I tried the compiler and sysroot from the build
>> CC=/ws/vms/vms-rsc-yocto-build/build_vms/tmp/sysroots/x86_64-linux/usr/bin/sh4-poky-linux/sh4-poky-linux-gcc
>> SYSROOT=/ws/vms/vms-rsc-yocto-build/build_vms/tmp/sysroots/sh7760
>>
>> hellomake: HelloWorld.c
>> $(CC) --sysroot=$(SYSROOT) -o HelloWorld HelloWorld.c
>>
>> and it compiles fine.
>>
>> So I ran $CC -print-search-dirs
>> install: 
>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/
>> programs: 
>> =/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/bin/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/bin/
>> libraries: 
>> =/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/lib/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/lib/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/usr/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/usr/lib/
>>
>> Then I checked that these files exist:
>> martin@martin-ubuntu-pconcepts:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux$
>> find $SDKTARGETSYSROOT -name "crt*"
>> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crtn.o
>> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crti.o
>> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crt1.o
>> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtendS.o
>> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtend.o
>> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtbeginT.o
>> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtbeginS.o
>> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtbegin.o
>>
>> Putting the library search directories on a sep

Re: [yocto] SDK Problems for SuperH 4

2016-10-06 Thread Khem Raj


> On Oct 6, 2016, at 12:09 PM, Martin Townsend  wrote:
> 
> On Thu, Oct 6, 2016 at 7:57 PM, Martin Townsend  
> wrote:
>> Hi,
>> 
>> We have a poky sato distributions successfully built and running for
>> our SuperH 4 processor board.  The problem is the SDK that is built
>> when using -cpopulate_sdk doesn't.
>> 
>> The simple Makefile:
>> hellomake: HelloWorld.c
>> $(CC) -o HelloWorld HelloWorld.c
> 
> Hit send before I had chance to finish :)
> 
> ignore the missing tab but when trying to compile (after sourcing the
> SDK environment) I get
> sh4-poky-linux-gcc  -ml -m4
> --sysroot=/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux -o HelloWorld
> HelloWorld.o
> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
> cannot find crt1.o: No such file or directory
> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
> cannot find crti.o: No such file or directory
> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
> cannot find crtbegin.o: No such file or directory
> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
> cannot find -lgcc
> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
> cannot find -lgcc_s
> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
> cannot find -lc
> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
> cannot find -lgcc
> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
> cannot find -lgcc_s
> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
> cannot find crtend.o: No such file or directory
> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
> cannot find crtn.o: No such file or directory
> 
> So I tried the compiler and sysroot from the build
> CC=/ws/vms/vms-rsc-yocto-build/build_vms/tmp/sysroots/x86_64-linux/usr/bin/sh4-poky-linux/sh4-poky-linux-gcc
> SYSROOT=/ws/vms/vms-rsc-yocto-build/build_vms/tmp/sysroots/sh7760
> 
> hellomake: HelloWorld.c
> $(CC) --sysroot=$(SYSROOT) -o HelloWorld HelloWorld.c
> 
> and it compiles fine.
> 
> So I ran $CC -print-search-dirs
> install: 
> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/
> programs: 
> =/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/bin/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/bin/
> libraries: 
> =/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/lib/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/lib/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/usr/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/usr/lib/
> 
> Then I checked that these files exist:
> martin@martin-ubuntu-pconcepts:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux$
> find $SDKTARGETSYSROOT -name "crt*"
> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crtn.o
> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crti.o
> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crt1.o
> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtendS.o
> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtend.o
> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtbeginT.o
> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtbeginS.o
> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtbegin.o
> 
> Putting the library search directories on a separate line
> martin@martin-ubuntu-pconcepts:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux$
> $CC -print-search-dir

Re: [yocto] SDK Problems for SuperH 4

2016-10-06 Thread Martin Townsend

On Thu, Oct 6, 2016 at 7:57 PM, Martin Townsend  wrote:
> Hi,
>
> We have a poky sato distributions successfully built and running for
> our SuperH 4 processor board.  The problem is the SDK that is built
> when using -cpopulate_sdk doesn't.
>
> The simple Makefile:
> hellomake: HelloWorld.c
> $(CC) -o HelloWorld HelloWorld.c

Hit send before I had chance to finish :)

ignore the missing tab but when trying to compile (after sourcing the
SDK environment) I get
sh4-poky-linux-gcc  -ml -m4
--sysroot=/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux -o HelloWorld
HelloWorld.o
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
cannot find crt1.o: No such file or directory
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
cannot find crti.o: No such file or directory
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
cannot find crtbegin.o: No such file or directory
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
cannot find -lgcc
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
cannot find -lgcc_s
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
cannot find -lc
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
cannot find -lgcc
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
cannot find -lgcc_s
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
cannot find crtend.o: No such file or directory
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
cannot find crtn.o: No such file or directory

So I tried the compiler and sysroot from the build
CC=/ws/vms/vms-rsc-yocto-build/build_vms/tmp/sysroots/x86_64-linux/usr/bin/sh4-poky-linux/sh4-poky-linux-gcc
SYSROOT=/ws/vms/vms-rsc-yocto-build/build_vms/tmp/sysroots/sh7760

hellomake: HelloWorld.c
$(CC) --sysroot=$(SYSROOT) -o HelloWorld HelloWorld.c

and it compiles fine.

So I ran $CC -print-search-dirs
install: 
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/
programs: 
=/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/bin/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/bin/
libraries: 
=/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/lib/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/lib/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/usr/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/usr/lib/

Then I checked that these files exist:
martin@martin-ubuntu-pconcepts:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux$
find $SDKTARGETSYSROOT -name "crt*"
/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crtn.o
/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crti.o
/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crt1.o
/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtendS.o
/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtend.o
/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtbeginT.o
/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtbeginS.o
/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtbegin.o

Putting the library search directories on a separate line
martin@martin-ubuntu-pconcepts:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux$
$CC -print-search-dirs | grep "^libraries:" | tr ':' '\n'
libraries
 
=/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/

[yocto] SDK Problems for SuperH 4

2016-10-06 Thread Martin Townsend

Hi,

We have a poky sato distributions successfully built and running for
our SuperH 4 processor board.  The problem is the SDK that is built
when using -cpopulate_sdk doesn't.

The simple Makefile:
hellomake: HelloWorld.c
$(CC) -o HelloWorld HelloWorld.c
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Trouble with yocto sdk in collaboration with eclipse and cmake

2016-08-01 Thread Hartwig, Guido

I saw that this issue is already solved in the masterbranch of the yocto 
eclipse plugin 
(http://git.yoctoproject.org/cgit/cgit.cgi/eclipse-poky/commit/?id=06fa262d309628e31648994c55324bc70f5d7dc8).
 Thank you for your support.

-Ursprüngliche Nachricht-
Von: Khem Raj [mailto:raj.k...@gmail.com] 
Gesendet: Montag, 1. August 2016 15:50
An: Hartwig, Guido 
Cc: yocto@yoctoproject.org
Betreff: Re: [yocto] Trouble with yocto sdk in collaboration with eclipse and 
cmake

On Mon, Aug 1, 2016 at 12:04 AM, Hartwig, Guido  wrote:
> I have manually added the flags from CC (-march=armv7-a -marm -mfpu=neon  
> -mfloat-abi=hard -mcpu=cortex-a8) to the OECMAKE_C_FLAGS and then it works. I 
> try to find a way, where CMAKE works out of the Box with yocto-plugin. I 
> think the plugin is the problem for this issue.

Please open a bug for this issue in bugzilla

>
> -Ursprüngliche Nachricht-
> Von: Khem Raj [mailto:raj.k...@gmail.com]
> Gesendet: Freitag, 29. Juli 2016 20:46
> An: Hartwig, Guido 
> Cc: yocto@yoctoproject.org
> Betreff: Re: [yocto] Trouble with yocto sdk in collaboration with 
> eclipse and cmake
>
>
>> On Jul 29, 2016, at 1:27 AM, Hartwig, Guido  wrote:
>>
>> Hi,
>> I have some trouble with the yocto sdk in collaboration with eclipse and 
>> yocto CMake project. I have install all necessary eclipse plugins and linked 
>> my sdk with the yocto-plugin as described in the manual. When I try to build 
>> the "Hello World" yocto cmake project it fails with following message:
>>
>> ..
>> CMake Error at
>> /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61 (message): The C 
>> compiler 
>> "/opt/puck/1.0.0/sysroots/x86_64-pucksdk-linux/usr/bin/arm-kostal-linux-gnueabi/arm-kostal-linux-gnueabi-gcc"
>>  is not able to compile a simple test program ...
>>
>> This error occurs because the compiler is called with the wrong flags.
>> The SDK environment-setup script export the following environment 
>> variables export CC="arm-kostal-linux-gnueabi-gcc  -march=armv7-a -marm 
>> -mfpu=neon  -mfloat-abi=hard -mcpu=cortex-a8 --sysroot=$SDKTARGETSYSROOT"
>> export CFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types 
>> -fdebug-prefix-map=/home/hartwig02/Workspace/build-puck/build/tmp/work/x86_64-nativesdk-pucksdk-linux/meta-environment-scb/1.0-r8=/usr/src/debug/meta-environment-scb/1.0-r8
>>  
>> -fdebug-prefix-map=/home/hartwig02/Workspace/build-puck/build/tmp/sysroots/x86_64-linux=
>>  
>> -fdebug-prefix-map=/home/hartwig02/Workspace/build-puck/build/tmp/sysroots/x86_64-nativesdk-pucksdk-linux=
>>  "
>>
>> The eclipse environment (set by the yocto plugin) shows the following 
>> environment:
>> CC = arm-kostal-linux-gnueabi-gcc  -march=armv7-a -marm -mfpu=neon 
>> -mfloat-abi=hard -mcpu=cortex-a8 
>> --sysroot=/opt/puck/1.0.0/sysroots/cortexa8hf-neon-kostal-linux-gnuea
>> b
>> i CFLAGS =
>> --sysroot=/opt/puck/1.0.0/sysroots/cortexa8hf-neon-kostal-linux-gnuea
>> b i OECMAKE_C_COMPILER = arm-kostal-linux-gnueabi-gcc
>> OECMAKE_C_FLAGS =
>> --sysroot=/opt/puck/1.0.0/sysroots/cortexa8hf-neon-kostal-linux-gnueabi
>>
>> I assume that yocto cmake uses the OECMAKE* variables to build the program.
>> The error occurs because the following compiler options (Tunes) are missing 
>> "-march=armv7-a -marm -mfpu=neon  -mfloat-abi=hard -mcpu=cortex-a8"
>>
>> Now my questions
>> 1.Is it right that the yocto plugin cuts off the tunes from the 
>> OECMAKE_C_COMPILER?
>> 2.Is there a reason that this compiler options are not appended to the 
>> CFLAGS?
>
> CFLAGS should be passed down to cmake build system. That seems to be the 
> problem you are seeing. Have you tried to append CFLAGS to OECMAKE_C_FLAGS ?
>
>>
>> Thank you for your help
>>
>>
>>
>> Mit freundlichen Grüßen / Kind regards
>>
>> KOSTAL Industrie Elektrik GmbH
>>
>> Dipl.-Ing.
>> Guido Hartwig
>> IE1 Entwicklung Elektronik
>> R & D Electronics
>>
>> Lange Eck 11, 58099 Hagen
>> Deutschland / Germany
>> Telefon: +49 2331 8040 - 688
>> Telefax: +49 2331 8040 - 4660
>> E-Mail: g.hart...@kostal.com
>>
>> Internet: http://www.kostal.com/industrie
>>
>>
>>
>> KOSTAL Industrie Elektrik GmbH - Sitz Lüdenscheid, Registergericht 
>> Iserlohn HRB 3924 - USt-Id-Nr./Vat No.: DE 813742170
>> Postanschrift: An der Bellmerei 10, D-58513 Lüdenscheid * Telefon: 
>> +49
>> 2351 16-0 * Telefax: +49 2351 16-2400
>> Werksanschrift: Lange Eck 11, D-58099 Hagen * Tel. +49 2331 8040-601 
>>

Re: [yocto] Trouble with yocto sdk in collaboration with eclipse and cmake

2016-08-01 Thread Andersen, Christian

Hi,

>> On Jul 29, 2016, at 1:27 AM, Hartwig, Guido  wrote:
>>
>> Hi,
>> I have some trouble with the yocto sdk in collaboration with eclipse and 
>> yocto CMake project. I have install all necessary eclipse plugins and linked 
>> my sdk with the yocto-plugin as described in the manual. When I try to build 
>> the "Hello World" yocto cmake project it fails with following message:
>>
>> ..
>> CMake Error at
>> /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61 (message): The C 
>> compiler 
>> "/opt/puck/1.0.0/sysroots/x86_64-pucksdk-linux/usr/bin/arm-kostal-linux-gnueabi/arm-kostal-linux-gnueabi-gcc"
>>  is not able to compile a simple test program ...
>>
>> This error occurs because the compiler is called with the wrong flags.

the error seems to be already fixed in the eclipse-poky repository. Commit 
#8315d3ec84 to luna/krogoth branch:

org.yocto.sdk.ide: Use CFLAGS from CC variable in cmake toolchain file
The CC and CXX variables imported from the Yocto build environment
may contain additional compiler flags after the compiler name. Extract
those and add them to cmake toolchain file variables, too.

This is the exact issue we have seen. Unfortunately this change has been 
commited after the tag for yocto-2.1 was created and so this is not released 
yet. After building a new version of the eclipse plugin based on the 
luna/krogoth branch the error mentioned above is gone.

Regards
Christian

KOSTAL Industrie Elektrik GmbH - Sitz Lüdenscheid, Registergericht Iserlohn HRB 
3924 - USt-Id-Nr./Vat No.: DE 813742170
Postanschrift: An der Bellmerei 10, D-58513 Lüdenscheid * Telefon: +49  2351 
16-0 * Telefax: +49  2351 16-2400
Werksanschrift: Lange Eck 11, D-58099 Hagen * Tel. +49 2331 8040-601 * Fax +49 
2331 8040-602
Geschäftsführung: Axel Zimmermann, Dipl.-Ing. Marwin Kinzl, Dipl.-Oec. Andreas 
Kostal

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Trouble with yocto sdk in collaboration with eclipse and cmake

2016-08-01 Thread Khem Raj

On Mon, Aug 1, 2016 at 12:04 AM, Hartwig, Guido  wrote:
> I have manually added the flags from CC (-march=armv7-a -marm -mfpu=neon  
> -mfloat-abi=hard -mcpu=cortex-a8) to the OECMAKE_C_FLAGS and then it works. I 
> try to find a way, where CMAKE works out of the Box with yocto-plugin. I 
> think the plugin is the problem for this issue.

Please open a bug for this issue in bugzilla

>
> -Ursprüngliche Nachricht-
> Von: Khem Raj [mailto:raj.k...@gmail.com]
> Gesendet: Freitag, 29. Juli 2016 20:46
> An: Hartwig, Guido 
> Cc: yocto@yoctoproject.org
> Betreff: Re: [yocto] Trouble with yocto sdk in collaboration with eclipse and 
> cmake
>
>
>> On Jul 29, 2016, at 1:27 AM, Hartwig, Guido  wrote:
>>
>> Hi,
>> I have some trouble with the yocto sdk in collaboration with eclipse and 
>> yocto CMake project. I have install all necessary eclipse plugins and linked 
>> my sdk with the yocto-plugin as described in the manual. When I try to build 
>> the "Hello World" yocto cmake project it fails with following message:
>>
>> ..
>> CMake Error at
>> /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61 (message): The C 
>> compiler 
>> "/opt/puck/1.0.0/sysroots/x86_64-pucksdk-linux/usr/bin/arm-kostal-linux-gnueabi/arm-kostal-linux-gnueabi-gcc"
>>  is not able to compile a simple test program ...
>>
>> This error occurs because the compiler is called with the wrong flags.
>> The SDK environment-setup script export the following environment
>> variables export CC="arm-kostal-linux-gnueabi-gcc  -march=armv7-a -marm 
>> -mfpu=neon  -mfloat-abi=hard -mcpu=cortex-a8 --sysroot=$SDKTARGETSYSROOT"
>> export CFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types 
>> -fdebug-prefix-map=/home/hartwig02/Workspace/build-puck/build/tmp/work/x86_64-nativesdk-pucksdk-linux/meta-environment-scb/1.0-r8=/usr/src/debug/meta-environment-scb/1.0-r8
>>  
>> -fdebug-prefix-map=/home/hartwig02/Workspace/build-puck/build/tmp/sysroots/x86_64-linux=
>>  
>> -fdebug-prefix-map=/home/hartwig02/Workspace/build-puck/build/tmp/sysroots/x86_64-nativesdk-pucksdk-linux=
>>  "
>>
>> The eclipse environment (set by the yocto plugin) shows the following 
>> environment:
>> CC = arm-kostal-linux-gnueabi-gcc  -march=armv7-a -marm -mfpu=neon
>> -mfloat-abi=hard -mcpu=cortex-a8
>> --sysroot=/opt/puck/1.0.0/sysroots/cortexa8hf-neon-kostal-linux-gnueab
>> i CFLAGS =
>> --sysroot=/opt/puck/1.0.0/sysroots/cortexa8hf-neon-kostal-linux-gnueab
>> i OECMAKE_C_COMPILER = arm-kostal-linux-gnueabi-gcc
>> OECMAKE_C_FLAGS =
>> --sysroot=/opt/puck/1.0.0/sysroots/cortexa8hf-neon-kostal-linux-gnueabi
>>
>> I assume that yocto cmake uses the OECMAKE* variables to build the program.
>> The error occurs because the following compiler options (Tunes) are missing 
>> "-march=armv7-a -marm -mfpu=neon  -mfloat-abi=hard -mcpu=cortex-a8"
>>
>> Now my questions
>> 1.Is it right that the yocto plugin cuts off the tunes from the 
>> OECMAKE_C_COMPILER?
>> 2.Is there a reason that this compiler options are not appended to the 
>> CFLAGS?
>
> CFLAGS should be passed down to cmake build system. That seems to be the 
> problem you are seeing. Have you tried to append CFLAGS to OECMAKE_C_FLAGS ?
>
>>
>> Thank you for your help
>>
>>
>>
>> Mit freundlichen Grüßen / Kind regards
>>
>> KOSTAL Industrie Elektrik GmbH
>>
>> Dipl.-Ing.
>> Guido Hartwig
>> IE1 Entwicklung Elektronik
>> R & D Electronics
>>
>> Lange Eck 11, 58099 Hagen
>> Deutschland / Germany
>> Telefon: +49 2331 8040 - 688
>> Telefax: +49 2331 8040 - 4660
>> E-Mail: g.hart...@kostal.com
>>
>> Internet: http://www.kostal.com/industrie
>>
>>
>>
>> KOSTAL Industrie Elektrik GmbH - Sitz Lüdenscheid, Registergericht
>> Iserlohn HRB 3924 - USt-Id-Nr./Vat No.: DE 813742170
>> Postanschrift: An der Bellmerei 10, D-58513 Lüdenscheid * Telefon: +49
>> 2351 16-0 * Telefax: +49 2351 16-2400
>> Werksanschrift: Lange Eck 11, D-58099 Hagen * Tel. +49 2331 8040-601 *
>> Fax +49 2331 8040-602
>> Geschäftsführung: Axel Zimmermann, Dipl.-Ing. Marwin Kinzl, Dipl.-Oec.
>> Andreas Kostal
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Trouble with yocto sdk in collaboration with eclipse and cmake

2016-07-31 Thread Hartwig, Guido

I have manually added the flags from CC (-march=armv7-a -marm -mfpu=neon  
-mfloat-abi=hard -mcpu=cortex-a8) to the OECMAKE_C_FLAGS and then it works. I 
try to find a way, where CMAKE works out of the Box with yocto-plugin. I think 
the plugin is the problem for this issue.

-Ursprüngliche Nachricht-
Von: Khem Raj [mailto:raj.k...@gmail.com] 
Gesendet: Freitag, 29. Juli 2016 20:46
An: Hartwig, Guido 
Cc: yocto@yoctoproject.org
Betreff: Re: [yocto] Trouble with yocto sdk in collaboration with eclipse and 
cmake


> On Jul 29, 2016, at 1:27 AM, Hartwig, Guido  wrote:
> 
> Hi,
> I have some trouble with the yocto sdk in collaboration with eclipse and 
> yocto CMake project. I have install all necessary eclipse plugins and linked 
> my sdk with the yocto-plugin as described in the manual. When I try to build 
> the "Hello World" yocto cmake project it fails with following message:
> 
> ..
> CMake Error at 
> /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61 (message): The C 
> compiler 
> "/opt/puck/1.0.0/sysroots/x86_64-pucksdk-linux/usr/bin/arm-kostal-linux-gnueabi/arm-kostal-linux-gnueabi-gcc"
>  is not able to compile a simple test program ...
> 
> This error occurs because the compiler is called with the wrong flags.
> The SDK environment-setup script export the following environment 
> variables export CC="arm-kostal-linux-gnueabi-gcc  -march=armv7-a -marm 
> -mfpu=neon  -mfloat-abi=hard -mcpu=cortex-a8 --sysroot=$SDKTARGETSYSROOT"
> export CFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types 
> -fdebug-prefix-map=/home/hartwig02/Workspace/build-puck/build/tmp/work/x86_64-nativesdk-pucksdk-linux/meta-environment-scb/1.0-r8=/usr/src/debug/meta-environment-scb/1.0-r8
>  
> -fdebug-prefix-map=/home/hartwig02/Workspace/build-puck/build/tmp/sysroots/x86_64-linux=
>  
> -fdebug-prefix-map=/home/hartwig02/Workspace/build-puck/build/tmp/sysroots/x86_64-nativesdk-pucksdk-linux=
>  "
> 
> The eclipse environment (set by the yocto plugin) shows the following 
> environment:
> CC = arm-kostal-linux-gnueabi-gcc  -march=armv7-a -marm -mfpu=neon  
> -mfloat-abi=hard -mcpu=cortex-a8 
> --sysroot=/opt/puck/1.0.0/sysroots/cortexa8hf-neon-kostal-linux-gnueab
> i CFLAGS =  
> --sysroot=/opt/puck/1.0.0/sysroots/cortexa8hf-neon-kostal-linux-gnueab
> i OECMAKE_C_COMPILER = arm-kostal-linux-gnueabi-gcc
> OECMAKE_C_FLAGS =
> --sysroot=/opt/puck/1.0.0/sysroots/cortexa8hf-neon-kostal-linux-gnueabi
> 
> I assume that yocto cmake uses the OECMAKE* variables to build the program.
> The error occurs because the following compiler options (Tunes) are missing 
> "-march=armv7-a -marm -mfpu=neon  -mfloat-abi=hard -mcpu=cortex-a8"
> 
> Now my questions
> 1.Is it right that the yocto plugin cuts off the tunes from the 
> OECMAKE_C_COMPILER?
> 2.Is there a reason that this compiler options are not appended to the 
> CFLAGS?

CFLAGS should be passed down to cmake build system. That seems to be the 
problem you are seeing. Have you tried to append CFLAGS to OECMAKE_C_FLAGS ?

> 
> Thank you for your help
> 
> 
> 
> Mit freundlichen Grüßen / Kind regards
> 
> KOSTAL Industrie Elektrik GmbH
> 
> Dipl.-Ing.
> Guido Hartwig
> IE1 Entwicklung Elektronik
> R & D Electronics
> 
> Lange Eck 11, 58099 Hagen
> Deutschland / Germany
> Telefon: +49 2331 8040 - 688
> Telefax: +49 2331 8040 - 4660
> E-Mail: g.hart...@kostal.com
> 
> Internet: http://www.kostal.com/industrie
> 
> 
> 
> KOSTAL Industrie Elektrik GmbH - Sitz Lüdenscheid, Registergericht 
> Iserlohn HRB 3924 - USt-Id-Nr./Vat No.: DE 813742170
> Postanschrift: An der Bellmerei 10, D-58513 Lüdenscheid * Telefon: +49  
> 2351 16-0 * Telefax: +49  2351 16-2400
> Werksanschrift: Lange Eck 11, D-58099 Hagen * Tel. +49 2331 8040-601 * 
> Fax +49 2331 8040-602
> Geschäftsführung: Axel Zimmermann, Dipl.-Ing. Marwin Kinzl, Dipl.-Oec. 
> Andreas Kostal
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Trouble with yocto sdk in collaboration with eclipse and cmake

2016-07-29 Thread Khem Raj


> On Jul 29, 2016, at 1:27 AM, Hartwig, Guido  wrote:
> 
> Hi,
> I have some trouble with the yocto sdk in collaboration with eclipse and 
> yocto CMake project. I have install all necessary eclipse plugins and linked 
> my sdk with the yocto-plugin as described in the manual. When I try to build 
> the "Hello World" yocto cmake project it fails with following message:
> 
> ..
> CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61 
> (message): The C compiler
> "/opt/puck/1.0.0/sysroots/x86_64-pucksdk-linux/usr/bin/arm-kostal-linux-gnueabi/arm-kostal-linux-gnueabi-gcc"
>  is not able to compile a simple test program
> ...
> 
> This error occurs because the compiler is called with the wrong flags.
> The SDK environment-setup script export the following environment variables
> export CC="arm-kostal-linux-gnueabi-gcc  -march=armv7-a -marm -mfpu=neon  
> -mfloat-abi=hard -mcpu=cortex-a8 --sysroot=$SDKTARGETSYSROOT"
> export CFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types 
> -fdebug-prefix-map=/home/hartwig02/Workspace/build-puck/build/tmp/work/x86_64-nativesdk-pucksdk-linux/meta-environment-scb/1.0-r8=/usr/src/debug/meta-environment-scb/1.0-r8
>  
> -fdebug-prefix-map=/home/hartwig02/Workspace/build-puck/build/tmp/sysroots/x86_64-linux=
>  
> -fdebug-prefix-map=/home/hartwig02/Workspace/build-puck/build/tmp/sysroots/x86_64-nativesdk-pucksdk-linux=
>  "
> 
> The eclipse environment (set by the yocto plugin) shows the following 
> environment:
> CC = arm-kostal-linux-gnueabi-gcc  -march=armv7-a -marm -mfpu=neon  
> -mfloat-abi=hard -mcpu=cortex-a8 
> --sysroot=/opt/puck/1.0.0/sysroots/cortexa8hf-neon-kostal-linux-gnueabi
> CFLAGS =  
> --sysroot=/opt/puck/1.0.0/sysroots/cortexa8hf-neon-kostal-linux-gnueabi
> OECMAKE_C_COMPILER = arm-kostal-linux-gnueabi-gcc
> OECMAKE_C_FLAGS =
> --sysroot=/opt/puck/1.0.0/sysroots/cortexa8hf-neon-kostal-linux-gnueabi
> 
> I assume that yocto cmake uses the OECMAKE* variables to build the program.
> The error occurs because the following compiler options (Tunes) are missing 
> "-march=armv7-a -marm -mfpu=neon  -mfloat-abi=hard -mcpu=cortex-a8"
> 
> Now my questions
> 1.Is it right that the yocto plugin cuts off the tunes from the 
> OECMAKE_C_COMPILER?
> 2.Is there a reason that this compiler options are not appended to the 
> CFLAGS?

CFLAGS should be passed down to cmake build system. That seems to be the 
problem you
are seeing. Have you tried to append CFLAGS to OECMAKE_C_FLAGS ?

> 
> Thank you for your help
> 
> 
> 
> Mit freundlichen Grüßen / Kind regards
> 
> KOSTAL Industrie Elektrik GmbH
> 
> Dipl.-Ing.
> Guido Hartwig
> IE1 Entwicklung Elektronik
> R & D Electronics
> 
> Lange Eck 11, 58099 Hagen
> Deutschland / Germany
> Telefon: +49 2331 8040 - 688
> Telefax: +49 2331 8040 - 4660
> E-Mail: g.hart...@kostal.com
> 
> Internet: http://www.kostal.com/industrie
> 
> 
> 
> KOSTAL Industrie Elektrik GmbH - Sitz Lüdenscheid, Registergericht Iserlohn 
> HRB 3924 - USt-Id-Nr./Vat No.: DE 813742170
> Postanschrift: An der Bellmerei 10, D-58513 Lüdenscheid * Telefon: +49  2351 
> 16-0 * Telefax: +49  2351 16-2400
> Werksanschrift: Lange Eck 11, D-58099 Hagen * Tel. +49 2331 8040-601 * Fax 
> +49 2331 8040-602
> Geschäftsführung: Axel Zimmermann, Dipl.-Ing. Marwin Kinzl, Dipl.-Oec. 
> Andreas Kostal
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Trouble with yocto sdk in collaboration with eclipse and cmake

2016-07-29 Thread Hartwig, Guido

Hi,
I have some trouble with the yocto sdk in collaboration with eclipse and yocto 
CMake project. I have install all necessary eclipse plugins and linked my sdk 
with the yocto-plugin as described in the manual. When I try to build the 
"Hello World" yocto cmake project it fails with following message:

..
CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61 
(message): The C compiler
 
"/opt/puck/1.0.0/sysroots/x86_64-pucksdk-linux/usr/bin/arm-kostal-linux-gnueabi/arm-kostal-linux-gnueabi-gcc"
  is not able to compile a simple test program
...

This error occurs because the compiler is called with the wrong flags.
The SDK environment-setup script export the following environment variables
export CC="arm-kostal-linux-gnueabi-gcc  -march=armv7-a -marm -mfpu=neon  
-mfloat-abi=hard -mcpu=cortex-a8 --sysroot=$SDKTARGETSYSROOT"
export CFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types 
-fdebug-prefix-map=/home/hartwig02/Workspace/build-puck/build/tmp/work/x86_64-nativesdk-pucksdk-linux/meta-environment-scb/1.0-r8=/usr/src/debug/meta-environment-scb/1.0-r8
 
-fdebug-prefix-map=/home/hartwig02/Workspace/build-puck/build/tmp/sysroots/x86_64-linux=
 
-fdebug-prefix-map=/home/hartwig02/Workspace/build-puck/build/tmp/sysroots/x86_64-nativesdk-pucksdk-linux=
 "

The eclipse environment (set by the yocto plugin) shows the following 
environment:
CC = arm-kostal-linux-gnueabi-gcc  -march=armv7-a -marm -mfpu=neon  
-mfloat-abi=hard -mcpu=cortex-a8 
--sysroot=/opt/puck/1.0.0/sysroots/cortexa8hf-neon-kostal-linux-gnueabi
CFLAGS =  
--sysroot=/opt/puck/1.0.0/sysroots/cortexa8hf-neon-kostal-linux-gnueabi
OECMAKE_C_COMPILER = arm-kostal-linux-gnueabi-gcc
OECMAKE_C_FLAGS =
--sysroot=/opt/puck/1.0.0/sysroots/cortexa8hf-neon-kostal-linux-gnueabi

I assume that yocto cmake uses the OECMAKE* variables to build the program. 
The error occurs because the following compiler options (Tunes) are missing 
"-march=armv7-a -marm -mfpu=neon  -mfloat-abi=hard -mcpu=cortex-a8"

Now my questions
1.  Is it right that the yocto plugin cuts off the tunes from the 
OECMAKE_C_COMPILER?
2.  Is there a reason that this compiler options are not appended to the 
CFLAGS?

Thank you for your help



Mit freundlichen Grüßen / Kind regards

KOSTAL Industrie Elektrik GmbH 

Dipl.-Ing.
Guido Hartwig 
IE1 Entwicklung Elektronik
R & D Electronics

Lange Eck 11, 58099 Hagen
Deutschland / Germany
Telefon: +49 2331 8040 - 688
Telefax: +49 2331 8040 - 4660
E-Mail: g.hart...@kostal.com

Internet: http://www.kostal.com/industrie



KOSTAL Industrie Elektrik GmbH - Sitz Lüdenscheid, Registergericht Iserlohn HRB 
3924 - USt-Id-Nr./Vat No.: DE 813742170
Postanschrift: An der Bellmerei 10, D-58513 Lüdenscheid * Telefon: +49  2351 
16-0 * Telefax: +49  2351 16-2400
Werksanschrift: Lange Eck 11, D-58099 Hagen * Tel. +49 2331 8040-601 * Fax +49 
2331 8040-602
Geschäftsführung: Axel Zimmermann, Dipl.-Ing. Marwin Kinzl, Dipl.-Oec. Andreas 
Kostal

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK

2015-11-16 Thread Martin Townsend

Hi Bryan,

Thank you for the reply.  I'm just doing a dry run with some sample
applications using the SDK and the command line and all is looking good.  I
didn't know about the "eclipse-debug" so I'll take a look at this.  Sadly
all the dev and dbg packages are probably not going to fit into the flash
but I'll keep a copy of the dbg packages somewhere in case a developer
wants to debug into a library.  They can scp it onto their board and
install it.  If I also include gdbserver and lttng packages for the target
then hopefully this should be a good start.

Regards,
Martin.





On Mon, Nov 16, 2015 at 6:25 PM, Bryan Evenson 
wrote:

> Martin,
>
> > -Original Message-
> > From: yocto-boun...@yoctoproject.org [mailto:yocto-
> > boun...@yoctoproject.org] On Behalf Of Martin Townsend
> > Sent: Saturday, November 14, 2015 9:27 AM
> > To: yocto@yoctoproject.org
> > Subject: [yocto] SDK
> >
> > Hi,
> >
> >
> >
> > I want to provide an SDK to the app developers that is a self contained
> > installation.  The ADT looked like just the thing except I don't want to
> have to
> > setup an ADT Repo.  I would like it to include:
> >
> >
> > The cross development toolchain.
> >
> > The target sysroot to build against.  I would like them to be able to
> > dynamically link and statically link against everything in the Image.
> >
> > They may want to develop kernel modules so I would want the kernel
> > header files etc in the target sysroot.
> >
> > The Eclipse IDE Yocto plug-in or another way of using Eclipse to build
> and
> > debug for the target.
> > I Would also like to use things like the LTTNG and Valgrind integration
> in
> > Eclipse.
> >
> > QEMU would be a nice to have and with integration into Eclipse.
> >
> >
> > I have my own distro and image files which aren't a million miles away
> from
> > poky and core-image-minimal :)
> >
> >
> > From what I've read I think the best thing for me to do is
> >
> > bitbake my-image -cpopulate_sdk
> >
> > which gives my an installer for the toolchain, target sysroot and qemu (I
> > think).
>
> You need to make sure your image includes the features for debugging.  If
> you have an image that is based upon core-image-minimal, the image will be
> missing some features and you'll never be able to debug an application
> through Eclipse or use Lttng.
>
> I'd suggest making a development image recipe (i.e. "
> my-custom-image-dev.bb") based on your image with the following changes:
> 1. Add "dev-pkgs eclipse-debug" to IMAGE_FEATURES
> 2. Add a "-dbg" package to IMAGE_INSTALL for each userspace application
> you are writing which you plan to debug with GDB.
> 3. Add "gdbserver" to IMAGE_INSTALL for GDB support.
> 4. Add "lttng-tools lttng-modules lttng-ust" to IMAGE_INSTALL for Lttng
> support.
>
> Once you've built and verified the new image runs on your hardware, I'd
> then create the SDK as you described above.  I don't use QEMU so I can't
> speak to whether that gets included in the SDK or not.  But, if you have a
> developer that isn't responsible for building the whole image and just
> wants to build and debug their userspace application, the SDK and resulting
> sysroot should be all the pieces they need on their development machine.
>
> Regards,
> Bryan
>
> >
> > Then get them to install the Eclipse plugin by following the
> instructions from
> > http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#adt-
> > eclipse
> >
> >
> > Just want to check I'm on the right path and there's not another better
> way.
> >
> >
> > Many Thanks,
> >
> > Martin.
> >
> >
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK

2015-11-16 Thread Bryan Evenson

Martin,

> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> boun...@yoctoproject.org] On Behalf Of Martin Townsend
> Sent: Saturday, November 14, 2015 9:27 AM
> To: yocto@yoctoproject.org
> Subject: [yocto] SDK
> 
> Hi,
> 
> 
> 
> I want to provide an SDK to the app developers that is a self contained
> installation.  The ADT looked like just the thing except I don't want to have 
> to
> setup an ADT Repo.  I would like it to include:
> 
> 
> The cross development toolchain.
> 
> The target sysroot to build against.  I would like them to be able to
> dynamically link and statically link against everything in the Image.
> 
> They may want to develop kernel modules so I would want the kernel
> header files etc in the target sysroot.
> 
> The Eclipse IDE Yocto plug-in or another way of using Eclipse to build and
> debug for the target.
> I Would also like to use things like the LTTNG and Valgrind integration in
> Eclipse.
> 
> QEMU would be a nice to have and with integration into Eclipse.
> 
> 
> I have my own distro and image files which aren't a million miles away from
> poky and core-image-minimal :)
> 
> 
> From what I've read I think the best thing for me to do is
> 
> bitbake my-image -cpopulate_sdk
> 
> which gives my an installer for the toolchain, target sysroot and qemu (I
> think).

You need to make sure your image includes the features for debugging.  If you 
have an image that is based upon core-image-minimal, the image will be missing 
some features and you'll never be able to debug an application through Eclipse 
or use Lttng.

I'd suggest making a development image recipe (i.e. "my-custom-image-dev.bb") 
based on your image with the following changes:
1. Add "dev-pkgs eclipse-debug" to IMAGE_FEATURES
2. Add a "-dbg" package to IMAGE_INSTALL for each userspace application you are 
writing which you plan to debug with GDB.
3. Add "gdbserver" to IMAGE_INSTALL for GDB support.
4. Add "lttng-tools lttng-modules lttng-ust" to IMAGE_INSTALL for Lttng support.

Once you've built and verified the new image runs on your hardware, I'd then 
create the SDK as you described above.  I don't use QEMU so I can't speak to 
whether that gets included in the SDK or not.  But, if you have a developer 
that isn't responsible for building the whole image and just wants to build and 
debug their userspace application, the SDK and resulting sysroot should be all 
the pieces they need on their development machine.

Regards,
Bryan

> 
> Then get them to install the Eclipse plugin by following the instructions from
> http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#adt-
> eclipse
> 
> 
> Just want to check I'm on the right path and there's not another better way.
> 
> 
> Many Thanks,
> 
> Martin.
> 
> 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] SDK

2015-11-14 Thread Martin Townsend

Hi,


I want to provide an SDK to the app developers that is a self contained
installation.  The ADT looked like just the thing except I don't want to
have to setup an ADT Repo.  I would like it to include:

The cross development toolchain.
The target sysroot to build against.  I would like them to be able to
dynamically link and statically link against everything in the Image.
They may want to develop kernel modules so I would want the kernel header
files etc in the target sysroot.
The Eclipse IDE Yocto plug-in or another way of using Eclipse to build and
debug for the target.
I Would also like to use things like the LTTNG and Valgrind integration in
Eclipse.
QEMU would be a nice to have and with integration into Eclipse.

I have my own distro and image files which aren't a million miles away from
poky and core-image-minimal :)

>From what I've read I think the best thing for me to do is
bitbake my-image -cpopulate_sdk
which gives my an installer for the toolchain, target sysroot and qemu (I
think).
Then get them to install the Eclipse plugin by following the instructions
from
http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#adt-eclipse

Just want to check I'm on the right path and there's not another better way.

Many Thanks,
Martin.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

1 2 >

1 - 100 of 148 matches

Mail list logo