External toolchain (sourcery)

External toolchain (sourcery)

[Laszlo Papp]

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

Hi,

is this officially supported by the Yocto project? I would not like to use
Yocto for my own purposes if it is something unsupported, and I would need
to put a significant investment into to it to make the releases buildable,
et cetera.

Many thanks,
Laszlo

[-- Attachment #2: Type: text/html, Size: 344 bytes --]

Re: External toolchain (sourcery)

[Christian Gagneraud]

On 25/07/13 02:49, Laszlo Papp wrote:
> Hi,
>
> is this officially supported by the Yocto project? I would not like to
> use Yocto for my own purposes if it is something unsupported, and I
> would need to put a significant investment into to it to make the
> releases buildable, et cetera.

FYI, The arago project uses an external Linaro toolchain [1]

Chris

[1] http://arago-project.org/wiki/index.php/Setting_Up_Build_Environment

>
> Many thanks,
> Laszlo
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: External toolchain (sourcery)

[Brian Hutchinson]

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

On Wed, Jul 24, 2013 at 10:49 AM, Laszlo Papp <lpapp@kde.org> wrote:

> Hi,
>
> is this officially supported by the Yocto project? I would not like to use
> Yocto for my own purposes if it is something unsupported, and I would need
> to put a significant investment into to it to make the releases buildable,
> et cetera.
>
> Many thanks,
> Laszlo
>
>
Check out the documentation but bitbake meta-toolchain or one of the
similar flavors should give you what you are looking for.

Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 872 bytes --]

Re: External toolchain (sourcery)

[Laszlo Papp]

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

1) Is that really from sourcery?
2) What documentation?
3) BTW, the question was whether sourcery is officially supported.


On Wed, Jul 24, 2013 at 9:55 PM, Brian Hutchinson <b.hutchman@gmail.com>wrote:

> On Wed, Jul 24, 2013 at 10:49 AM, Laszlo Papp <lpapp@kde.org> wrote:
>
>> Hi,
>>
>> is this officially supported by the Yocto project? I would not like to
>> use Yocto for my own purposes if it is something unsupported, and I would
>> need to put a significant investment into to it to make the releases
>> buildable, et cetera.
>>
>> Many thanks,
>> Laszlo
>>
>>
> Check out the documentation but bitbake meta-toolchain or one of the
> similar flavors should give you what you are looking for.
>
> Regards,
>
> Brian
>

[-- Attachment #2: Type: text/html, Size: 1704 bytes --]

Re: External toolchain (sourcery)

[Brian Hutchinson]

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

On Wed, Jul 24, 2013 at 4:59 PM, Laszlo Papp <lpapp@kde.org> wrote:

> 1) Is that really from sourcery?
> 2) What documentation?
> 3) BTW, the question was whether sourcery is officially supported.
>
>
> Yocto's default action is to build the toolchain from source and no it
isn't Code Sourcery if that is what you are wanting to know.  You can
configure Yocto to not build the toolchain and use one you provide but I've
never tried it.

https://www.yoctoproject.org/documentation/current should give you light
bedtime reading material.

Angstrom & Arago as mentioned before use Linaro which has all the latest
ARM patches.

Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 1388 bytes --]

Re: External toolchain (sourcery)

[Chris Larson]

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

On Wed, Jul 24, 2013 at 1:55 PM, Brian Hutchinson <b.hutchman@gmail.com>wrote:

> On Wed, Jul 24, 2013 at 10:49 AM, Laszlo Papp <lpapp@kde.org> wrote:
>
>> is this officially supported by the Yocto project? I would not like to
>> use Yocto for my own purposes if it is something unsupported, and I would
>> need to put a significant investment into to it to make the releases
>> buildable, et cetera.
>>
>
I'm not certain as to the official Yocto support stance on
external-sourcery as it exists in or-core at this time, but if you do want
to use the Sourcery G++ toolchain rather than one of the alternatives
suggested by others in this thread, you can use the meta-sourcery layer,
which while it isn't officially supported by Yocto, is officially supported
by Mentor Graphics, the company which provides the aforementioned toolchain.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 1674 bytes --]

Re: External toolchain (sourcery)

[Laszlo Papp]

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

I believe the developer story would be simpler with oe-core as opposed to
meta-sourcery. Besides, some documentation would be nice to have how to use
it, how it will work alongside the oe-core "example", and so forth.

You know, something similar to what the Linaro people seem to have.


On Wed, Jul 24, 2013 at 9:59 PM, Chris Larson <clarson@kergoth.com> wrote:

> On Wed, Jul 24, 2013 at 1:55 PM, Brian Hutchinson <b.hutchman@gmail.com>wrote:
>
>> On Wed, Jul 24, 2013 at 10:49 AM, Laszlo Papp <lpapp@kde.org> wrote:
>>
>>> is this officially supported by the Yocto project? I would not like to
>>> use Yocto for my own purposes if it is something unsupported, and I would
>>> need to put a significant investment into to it to make the releases
>>> buildable, et cetera.
>>>
>>
> I'm not certain as to the official Yocto support stance on
> external-sourcery as it exists in or-core at this time, but if you do want
> to use the Sourcery G++ toolchain rather than one of the alternatives
> suggested by others in this thread, you can use the meta-sourcery layer,
> which while it isn't officially supported by Yocto, is officially supported
> by Mentor Graphics, the company which provides the aforementioned toolchain.
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
>

[-- Attachment #2: Type: text/html, Size: 2519 bytes --]

Re: External toolchain (sourcery)

[Laszlo Papp]

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

Also, it seems to be a bit less lightweight than what we have in oe-core. I
would not like to pull unnecessary recipes in. Is it possible to work the
oe-core stuff around?


On Wed, Jul 24, 2013 at 10:23 PM, Laszlo Papp <lpapp@kde.org> wrote:

> I believe the developer story would be simpler with oe-core as opposed to
> meta-sourcery. Besides, some documentation would be nice to have how to use
> it, how it will work alongside the oe-core "example", and so forth.
>
> You know, something similar to what the Linaro people seem to have.
>
>
> On Wed, Jul 24, 2013 at 9:59 PM, Chris Larson <clarson@kergoth.com> wrote:
>
>> On Wed, Jul 24, 2013 at 1:55 PM, Brian Hutchinson <b.hutchman@gmail.com>wrote:
>>
>>> On Wed, Jul 24, 2013 at 10:49 AM, Laszlo Papp <lpapp@kde.org> wrote:
>>>
>>>> is this officially supported by the Yocto project? I would not like to
>>>> use Yocto for my own purposes if it is something unsupported, and I would
>>>> need to put a significant investment into to it to make the releases
>>>> buildable, et cetera.
>>>>
>>>
>> I'm not certain as to the official Yocto support stance on
>> external-sourcery as it exists in or-core at this time, but if you do want
>> to use the Sourcery G++ toolchain rather than one of the alternatives
>> suggested by others in this thread, you can use the meta-sourcery layer,
>> which while it isn't officially supported by Yocto, is officially supported
>> by Mentor Graphics, the company which provides the aforementioned toolchain.
>>  --
>> Christopher Larson
>> clarson at kergoth dot com
>> Founder - BitBake, OpenEmbedded, OpenZaurus
>> Maintainer - Tslib
>> Senior Software Engineer, Mentor Graphics
>>
>
>

[-- Attachment #2: Type: text/html, Size: 3055 bytes --]

Re: External toolchain (sourcery)

[Laszlo Papp]

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

So, is there any workaround in any way to get unblocked or I should just
switch away from Yocto for now? Unfortunately, if no workaround comes, I do
not have any other option because then it just does not work. :(

https://bugzilla.yoctoproject.org/show_bug.cgi?id=4899

Note, I have no clue how to use the meta-sourcery layer, and it has no any
proper documentation about that, nor example, like the Linaro guys nicely
made one for their solution.


On Wed, Jul 24, 2013 at 10:32 PM, Laszlo Papp <lpapp@kde.org> wrote:

> Also, it seems to be a bit less lightweight than what we have in oe-core.
> I would not like to pull unnecessary recipes in. Is it possible to work the
> oe-core stuff around?
>
>
> On Wed, Jul 24, 2013 at 10:23 PM, Laszlo Papp <lpapp@kde.org> wrote:
>
>> I believe the developer story would be simpler with oe-core as opposed to
>> meta-sourcery. Besides, some documentation would be nice to have how to use
>> it, how it will work alongside the oe-core "example", and so forth.
>>
>> You know, something similar to what the Linaro people seem to have.
>>
>>
>> On Wed, Jul 24, 2013 at 9:59 PM, Chris Larson <clarson@kergoth.com>wrote:
>>
>>> On Wed, Jul 24, 2013 at 1:55 PM, Brian Hutchinson <b.hutchman@gmail.com>wrote:
>>>
>>>> On Wed, Jul 24, 2013 at 10:49 AM, Laszlo Papp <lpapp@kde.org> wrote:
>>>>
>>>>> is this officially supported by the Yocto project? I would not like to
>>>>> use Yocto for my own purposes if it is something unsupported, and I would
>>>>> need to put a significant investment into to it to make the releases
>>>>> buildable, et cetera.
>>>>>
>>>>
>>> I'm not certain as to the official Yocto support stance on
>>> external-sourcery as it exists in or-core at this time, but if you do want
>>> to use the Sourcery G++ toolchain rather than one of the alternatives
>>> suggested by others in this thread, you can use the meta-sourcery layer,
>>> which while it isn't officially supported by Yocto, is officially supported
>>> by Mentor Graphics, the company which provides the aforementioned toolchain.
>>>  --
>>> Christopher Larson
>>> clarson at kergoth dot com
>>> Founder - BitBake, OpenEmbedded, OpenZaurus
>>> Maintainer - Tslib
>>> Senior Software Engineer, Mentor Graphics
>>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4032 bytes --]

Re: External toolchain (sourcery)

[Laszlo Papp]

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

I filed a bugreport against meta-sourcery:
https://github.com/MentorEmbedded/meta-sourcery/issues/9

It is very surprising to see a project without an actual documentation.
Perhaps, it has been mostly used for internal purposes where the developers
of the stuff were also the end users. That has to be fixed.


On Thu, Jul 25, 2013 at 5:53 AM, Laszlo Papp <lpapp@kde.org> wrote:

> So, is there any workaround in any way to get unblocked or I should just
> switch away from Yocto for now? Unfortunately, if no workaround comes, I do
> not have any other option because then it just does not work. :(
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4899
>
> Note, I have no clue how to use the meta-sourcery layer, and it has no any
> proper documentation about that, nor example, like the Linaro guys nicely
> made one for their solution.
>
>
> On Wed, Jul 24, 2013 at 10:32 PM, Laszlo Papp <lpapp@kde.org> wrote:
>
>> Also, it seems to be a bit less lightweight than what we have in oe-core.
>> I would not like to pull unnecessary recipes in. Is it possible to work the
>> oe-core stuff around?
>>
>>
>> On Wed, Jul 24, 2013 at 10:23 PM, Laszlo Papp <lpapp@kde.org> wrote:
>>
>>> I believe the developer story would be simpler with oe-core as opposed
>>> to meta-sourcery. Besides, some documentation would be nice to have how to
>>> use it, how it will work alongside the oe-core "example", and so forth.
>>>
>>> You know, something similar to what the Linaro people seem to have.
>>>
>>>
>>> On Wed, Jul 24, 2013 at 9:59 PM, Chris Larson <clarson@kergoth.com>wrote:
>>>
>>>> On Wed, Jul 24, 2013 at 1:55 PM, Brian Hutchinson <b.hutchman@gmail.com
>>>> > wrote:
>>>>
>>>>> On Wed, Jul 24, 2013 at 10:49 AM, Laszlo Papp <lpapp@kde.org> wrote:
>>>>>
>>>>>> is this officially supported by the Yocto project? I would not like
>>>>>> to use Yocto for my own purposes if it is something unsupported, and I
>>>>>> would need to put a significant investment into to it to make the releases
>>>>>> buildable, et cetera.
>>>>>>
>>>>>
>>>> I'm not certain as to the official Yocto support stance on
>>>> external-sourcery as it exists in or-core at this time, but if you do want
>>>> to use the Sourcery G++ toolchain rather than one of the alternatives
>>>> suggested by others in this thread, you can use the meta-sourcery layer,
>>>> which while it isn't officially supported by Yocto, is officially supported
>>>> by Mentor Graphics, the company which provides the aforementioned toolchain.
>>>>  --
>>>> Christopher Larson
>>>> clarson at kergoth dot com
>>>> Founder - BitBake, OpenEmbedded, OpenZaurus
>>>> Maintainer - Tslib
>>>> Senior Software Engineer, Mentor Graphics
>>>>
>>>
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4860 bytes --]

Re: External toolchain (sourcery)

[Laszlo Papp]

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

TCMODE = "external-csl"
EXTERNAL_TOOLCHAIN = "/usr/local/arm-2009q1"
TARGET_PREFIX = "arm-none-linux-gnueabi-"

INSANE_SKIP_external-sourcery-toolchain-dev += "ldflags"

PREFERRED_PROVIDER_linux-libc-headers = "external-sourcery-toolchain"
PREFERRED_PROVIDER_linux-libc-headers-dev = "external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc =
"external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc-initial =
"external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc-intermediate =
"external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}g++ =
"external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}binutils =
"external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}libc-initial =
"external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}libc-for-gcc =
"external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}compilerlibs =
"external-sourcery-toolchain"
PREFERRED_PROVIDER_libgcc = "external-sourcery-toolchain"
PREFERRED_PROVIDER_eglibc = "external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/libc = "external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/libintl = "external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/libiconv = "external-sourcery-toolchain"
PREFERRED_PROVIDER_glibc-thread-db = "external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/linux-libc-headers =
"external-sourcery-toolchain"
PREFERRED_PROVIDER_virtual/linux-libc-headers-dev =
"external-sourcery-toolchain"
PREFERRED_PROVIDER_gdbserver = "external-sourcery-toolchain"

For the setup above, I am getting the error below:

bitbake core-image-minimal
Pseudo is not present but is required, building this first before the main
build
Parsing recipes: 100%
|######################################################################################################################################################################################################|
Time: 00:00:27
Parsing of 831 .bb files complete (0 cached, 831 parsed). 1140 targets, 51
skipped, 0 masked, 0 errors.

Build Configuration:
BB_VERSION        = "1.18.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "arch-rolling"
TARGET_SYS        = "arm-foo-linux-gnueabi"
MACHINE           = "foo"
DISTRO            = "foo"
DISTRO_VERSION    = "0.1"
TUNE_FEATURES     = "armv5 thumb dsp"
TARGET_FPU        = "soft"
meta
meta-yocto
meta-yocto-bsp    = "master:3d4147a43126a7b031ac583221012442dde7beab"
meta-sourcery     = "master:832ce1937780bbb508050f02ac8a8bf309045fef"
meta-foo      = "master:3d4147a43126a7b031ac583221012442dde7beab"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 63 tasks of which 0 didn't need to be rerun
and all succeeded.
Loading cache: 100%
|########################################################################################################################################################################################################|
ETA:  00:00:00
Loaded 1141 entries from dependency cache.

Build Configuration:
BB_VERSION        = "1.18.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "arch-rolling"
TARGET_SYS        = "arm-foo-linux-gnueabi"
MACHINE           = "foo"
DISTRO            = "foo"
DISTRO_VERSION    = "0.1"
TUNE_FEATURES     = "armv5 thumb dsp"
TARGET_FPU        = "soft"
meta
meta-yocto
meta-yocto-bsp    = "master:3d4147a43126a7b031ac583221012442dde7beab"
meta-sourcery     = "master:832ce1937780bbb508050f02ac8a8bf309045fef"
meta-foo      = "master:3d4147a43126a7b031ac583221012442dde7beab"

NOTE: Resolving any missing task queue dependencies
NOTE: preferred version 141 of udev not available (for item udev)
NOTE: versions of udev available: 182
NOTE: preferred version 141 of udev not available (for item udev-dev)
NOTE: versions of udev available: 182
NOTE: preferred version 141 of udev not available (for item udev-utils)
NOTE: versions of udev available: 182
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: Failed to fetch URL http://www.zlib.net/zlib-1.2.7.tar.bz2,
attempting MIRRORS if available
No currently running tasks (83 of 1366)
ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded:
ignored.
ERROR: Function failed: do_install (see
/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/foo-builds/tmp/work/armv5te-foo-linux-gnueabi/external-sourcery-toolchain/2009q1-203-r22/temp/log.do_install.25593
for further information)
ERROR: Logfile of failure stored in:
/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/foo-builds/tmp/work/armv5te-foo-linux-gnueabi/external-sourcery-toolchain/2009q1-203-r22/temp/log.do_install.25593
Log data follows:
| ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded:
ignored.
| DEBUG: Executing shell function do_install
| cp: target
'/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/foo-builds/tmp/work/armv5te-foo-linux-gnueabi/external-sourcery-toolchain/2009q1-203-r22/image/lib'
is not a directory
| ERROR: Function failed: do_install (see
/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/foo-builds/tmp/work/armv5te-foo-linux-gnueabi/external-sourcery-toolchain/2009q1-203-r22/temp/log.do_install.25593
for further information)
ERROR: Task 31
(/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta-sourcery/recipes/meta/
external-sourcery-toolchain.bb, do_install) failed with exit code '1'
NOTE: Tasks Summary: Attempted 83 tasks of which 63 didn't need to be rerun
and 1 failed.
No currently running tasks (83 of 1366)

Summary: 1 task failed:

/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta-sourcery/recipes/meta/
external-sourcery-toolchain.bb, do_install
Summary: There was 1 WARNING message shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.


On Thu, Jul 25, 2013 at 1:48 PM, Laszlo Papp <lpapp@kde.org> wrote:

> I filed a bugreport against meta-sourcery:
> https://github.com/MentorEmbedded/meta-sourcery/issues/9
>
> It is very surprising to see a project without an actual documentation.
> Perhaps, it has been mostly used for internal purposes where the developers
> of the stuff were also the end users. That has to be fixed.
>
>
> On Thu, Jul 25, 2013 at 5:53 AM, Laszlo Papp <lpapp@kde.org> wrote:
>
>> So, is there any workaround in any way to get unblocked or I should just
>> switch away from Yocto for now? Unfortunately, if no workaround comes, I do
>> not have any other option because then it just does not work. :(
>>
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4899
>>
>> Note, I have no clue how to use the meta-sourcery layer, and it has no
>> any proper documentation about that, nor example, like the Linaro guys
>> nicely made one for their solution.
>>
>>
>> On Wed, Jul 24, 2013 at 10:32 PM, Laszlo Papp <lpapp@kde.org> wrote:
>>
>>> Also, it seems to be a bit less lightweight than what we have in
>>> oe-core. I would not like to pull unnecessary recipes in. Is it possible to
>>> work the oe-core stuff around?
>>>
>>>
>>> On Wed, Jul 24, 2013 at 10:23 PM, Laszlo Papp <lpapp@kde.org> wrote:
>>>
>>>> I believe the developer story would be simpler with oe-core as opposed
>>>> to meta-sourcery. Besides, some documentation would be nice to have how to
>>>> use it, how it will work alongside the oe-core "example", and so forth.
>>>>
>>>> You know, something similar to what the Linaro people seem to have.
>>>>
>>>>
>>>> On Wed, Jul 24, 2013 at 9:59 PM, Chris Larson <clarson@kergoth.com>wrote:
>>>>
>>>>> On Wed, Jul 24, 2013 at 1:55 PM, Brian Hutchinson <
>>>>> b.hutchman@gmail.com> wrote:
>>>>>
>>>>>> On Wed, Jul 24, 2013 at 10:49 AM, Laszlo Papp <lpapp@kde.org> wrote:
>>>>>>
>>>>>>> is this officially supported by the Yocto project? I would not like
>>>>>>> to use Yocto for my own purposes if it is something unsupported, and I
>>>>>>> would need to put a significant investment into to it to make the releases
>>>>>>> buildable, et cetera.
>>>>>>>
>>>>>>
>>>>> I'm not certain as to the official Yocto support stance on
>>>>> external-sourcery as it exists in or-core at this time, but if you do want
>>>>> to use the Sourcery G++ toolchain rather than one of the alternatives
>>>>> suggested by others in this thread, you can use the meta-sourcery layer,
>>>>> which while it isn't officially supported by Yocto, is officially supported
>>>>> by Mentor Graphics, the company which provides the aforementioned toolchain.
>>>>>  --
>>>>> Christopher Larson
>>>>> clarson at kergoth dot com
>>>>> Founder - BitBake, OpenEmbedded, OpenZaurus
>>>>> Maintainer - Tslib
>>>>> Senior Software Engineer, Mentor Graphics
>>>>>
>>>>
>>>>
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 13018 bytes --]