Re: [yocto] Building clang with Yocto
I tried ldd-ing my binary on my build machine since it doesn't work on my image and it was built on glibc indeed. Since yocto is based on ulibc so it won't work even my target platform is roughly the same as my build platform. I wonder what options should I specify to get llvm to build against the Yocto's libraries rather than my build machine's. As I said in IRC yesterday I found https://lists.yoctoproject.org/pipermail/yocto/2014-June/020358.html which should suit my needs but I get stupid errors on uint32_t: /work/corei7-64-poky-linux/llvm/3.3-r0/llvm -3.3.src/include/llvm/Support/BranchProbability.h:27:3: error: 'uint32_t' does not name a type uint32_t N; I tried adding #include to that header but no luck. -Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Sent: Monday, December 22, 2014 7:22 PM To: Yu, Chan KitX Cc: 'Liviu Gheorghisan'; 'Jim Rafert'; yocto@yoctoproject.org Subject: Re: [yocto] Building clang with Yocto Hi Chan Kit, On Monday 22 December 2014 03:33:17 Yu, Chan KitX wrote: > Here's an update FYI. I have managed to get clang sort of working. It > compiles my sample code but I can't get the binary to execute. ./a.out > simply returns: > > > ./a.out: No such file or directory. > > I'm sure that a.out exists and weirdly I could get the same binary > file to run on my build machine. So I guess it could be because of > some architecture difference but both target and build platform are > quite the same (Intel x64 in build machine and BayleyBay for target > platform) I used > valleyisland-64 for the target platform so both should be able to > execute > 64 bit binaries. I suppose I can specify some other configuration > options there but I have no idea what to specify the configure > parameter --target= . x64 did not do any good. So any idea? That sounds a bit like the binary has been linked to libraries in the host libdir rather than the correct one for the target. You may be able to verify that using ldd. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Cross compiler which runs on the target architecture.
On Sat, 2014-12-20 at 14:43 +, Peter Saunderson wrote:
> I have seen a brief IRC chat
> (https://www.yoctoproject.org/irc/%23yocto.2013-09-23.log.html talking
> about https://github.com/nathanrossi/meta-parallella) about this
> question but nothing much else so this is an attempt to get more public
> feedback on this request.
>
> I am trying to build a cross compiler that runs on the target processor
> and a cross compiler that runs on the host processor so that I can build
> code for a third processor (Epiphany). If you want examples of the
> traditional way to build this compiler look at
> https://github.com/adapteva/epiphany-sdk epiphany-gcc epiphany-newlib
> epiphany-binutils... The end result would be a set of recipes that run
> on a pc build machine that build both arm code for the interim target
> and epiphany code for the final target and provides an SDK for the pc
> that enables you to cross compile for both arm and epiphany.
>
> As I am just starting to look at this I would like to know what size of
> task I am up against! My initial efforts based on review of
> poky/meta/recipes-devtools/binutils etc seem to suggest that I have to
> modify at least ${HOST_PREFIX}, ${TARGET_PREFIX}, ${TARGET_ARCH} etc for
> my epiphany-??? recipes so that the I can install the compiler in a
> suitable location with a suitable prefix, the IRC chat indicates that
> there are more things to consider also.
>
> The question I have is about how easy it will be to use existing recipes
> for existing compiler / binutils etc... or is this likely to end up as a
> completely new set of recipes from the ground up because the existing
> recipes cant cope with building cross / cross compilers where there are
> three processors to consider (host (intel based pc), interim target
> (arm) and final target (epiphany)), or at least a lot of changes in the
> existing recipes to cope with something like TARGET_TARGET_ARCH =
> ${TARGET_ARCH}_${FINAL_TARGET_ARCH}??
As mentioned, I had need to do something like this for an avr target.
I've created some *extremely* hacky recipes which do this and the
resulting toolchain does actually work, much to my surprise. I've
included the recipes I created below, warts and all in case it helps.
Basically, its all a bit of a hack, the trouble is the system is very
much tuned to have TARGET pointed at HOST for standard recipes. In the
end I found it easier to 'sed' in the right target values into configure
and then 'sed' other variables to change TARGET_PREFIX/TARGET_SYS where
needed.
Ultimately if we were doing a lot of this, we may be able to use a
different variable name to make the recipes a lot neater.
Cheers,
Richard
>From f58f90257a5af3e6b6974090e62cad9d90d53ae5 Mon Sep 17 00:00:00 2001
From: Richard Purdie
Date: Tue, 23 Dec 2014 09:01:34 +
Subject: Add target avr support
Known issues:
* dependencies between the recipes is missing/incorrect
* on target avr libgcc isn't installed
Signed-off-by: Richard Purdie
diff --git a/meta/recipes-devtools/avr-libc/avr-libc_1.8.1.bb
b/meta/recipes-devtools/avr-libc/avr-libc_1.8.1.bb
new file mode 100644
index 000..81481ba
--- /dev/null
+++ b/meta/recipes-devtools/avr-libc/avr-libc_1.8.1.bb
@@ -0,0 +1,31 @@
+SRC_URI =
"http://download.savannah.gnu.org/releases/avr-libc/avr-libc-1.8.1.tar.bz2";
+LICENSE = "BSD"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=8d91a8f153d3de715f67a5df0d841c43"
+
+SRC_URI[md5sum] = "0caccead59eaaa61ac3f060ca3a803ef"
+SRC_URI[sha256sum] =
"c3062a481b6b2c6959dc708571c00b0e26301897ba21171ed92acd0af7c4a969"
+
+inherit autotools
+
+TOOLCHAIN_OPTIONS = ""
+
+TARGET_CFLAGS = ""
+TARGET_LDFLAGS = ""
+
+export CC = "avr-gcc"
+export AS = "avr-as"
+export RANLIB = "avr-ranlib"
+export AR = "avr-ar"
+
+FILES_${PN} += "${exec_prefix}/avr"
+INSANE_SKIP_${PN} = "arch staticdev"
+
+python () {
+def replace(var, x, y):
+d.setVar(var, d.getVar(var, True).replace(d.expand(x),y))
+
+replace('CONFIGUREOPTS', '--host=${HOST_SYS}','--host=avr')
+replace('CONFIGUREOPTS', '--target=${TARGET_SYS}','--target=avr')
+}
+
+
diff --git a/meta/recipes-devtools/binutils/binutils-cross-target-avr_2.24.bb
b/meta/recipes-devtools/binutils/binutils-cross-target-avr_2.24.bb
new file mode 100644
index 000..e19cf54
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils-cross-target-avr_2.24.bb
@@ -0,0 +1,37 @@
+require binutils.inc
+require binutils-${PV}.inc
+require binutils-cross.inc
+
+DEPENDS += "flex bison zlib"
+PROVIDES = "virtual/binutils-target-avr"
+
+BPN = "binutils"
+
+
+
+python () {
+def replace(var, x, y):
+d.setVar(var, d.getVar(var, True).replace(d.expand(x),y))
+
+replace('CONFIGUREOPTS', '--target=${TARGET_SYS}','--target=avr')
+replace('EXTRA_OECONF', '--program-prefix=${TARGET_PREFIX}'
,'--program-prefix=avr-')
+replace('do_install', '${TARGET_PREFIX}' ,'avr-')
+replace('do_install', '${TARGET_SYS}' ,'avr')
+}
+
+EXTRA_OECONF += "--with-sy
Re: [yocto] Cross compiler which runs on the target architecture.
On Tue, Dec 23, 2014 at 12:53 AM, Richard Purdie
wrote:
> Hi,
>
> On Sat, 2014-12-20 at 14:43 +, Peter Saunderson wrote:
>> I have seen a brief IRC chat
>> (https://www.yoctoproject.org/irc/%23yocto.2013-09-23.log.html talking
>> about https://github.com/nathanrossi/meta-parallella) about this
>> question but nothing much else so this is an attempt to get more public
>> feedback on this request.
That was me, as you might have noticed I ended up for now just using a
pre-built toolchain that was copied into the system image with a
recipe. This works but its not ideal.
There have been a few threads recently regarding similar functionality desires:
* https://lists.yoctoproject.org/pipermail/yocto/2014-December/022751.html
* https://lists.yoctoproject.org/pipermail/yocto/2014-December/022653.html
(this one is more about multi-machine builds, but still relevant)
>>
>> I am trying to build a cross compiler that runs on the target processor
>> and a cross compiler that runs on the host processor so that I can build
>> code for a third processor (Epiphany). If you want examples of the
>> traditional way to build this compiler look at
>> https://github.com/adapteva/epiphany-sdk epiphany-gcc epiphany-newlib
>> epiphany-binutils... The end result would be a set of recipes that run
>> on a pc build machine that build both arm code for the interim target
>> and epiphany code for the final target and provides an SDK for the pc
>> that enables you to cross compile for both arm and epiphany.
I have been interested in this myself for the epiphany case as well as
a few additional cases (from a personal interest as well as for
Xilinx/meta-xilinx):
* epiphany native, nativesdk and target cross compilers
* baremetal toolchain (using newlib)
* canadian-cross arch baremetal (e.g. arm host building for
microblaze baremetal)
* and also (canadian-)cross arch linux
>>
>> As I am just starting to look at this I would like to know what size of
>> task I am up against! My initial efforts based on review of
>> poky/meta/recipes-devtools/binutils etc seem to suggest that I have to
>> modify at least ${HOST_PREFIX}, ${TARGET_PREFIX}, ${TARGET_ARCH} etc for
>> my epiphany-??? recipes so that the I can install the compiler in a
>> suitable location with a suitable prefix, the IRC chat indicates that
>> there are more things to consider also.
>>
>> The question I have is about how easy it will be to use existing recipes
>> for existing compiler / binutils etc... or is this likely to end up as a
>> completely new set of recipes from the ground up because the existing
>> recipes cant cope with building cross / cross compilers where there are
>> three processors to consider (host (intel based pc), interim target
>> (arm) and final target (epiphany)), or at least a lot of changes in the
>> existing recipes to cope with something like TARGET_TARGET_ARCH =
>> ${TARGET_ARCH}_${FINAL_TARGET_ARCH}??
>
> Funnily enough I've a similar need to do something like this for a
> personal project but targeting AVR.
>
> Certainly OE has the power and capability to do something like this, I'm
> not sure its straightforward though, at least generically, and I say
> that as one of the people with pretty intimate knowledge of the
> toolchain recipes.
>
> The easy parts are creating recipes for binutils and gcc to run on the
> target, targeting a third arch. This is like cross-canadian but built to
> run on MACHINE instead of SDKMACHINE and taretting a new arch (probably
> 'target-cross-canadian'). The massively harder part is the libc for gcc
> to build against and any other libs for the system.
>
> The issue is that bitbake.conf locks the choice of MACHINE early in the
> configuration stage. We added SDKMACHINE as a way of letting us build
> SDKs and we have multilib and BBCLASSEXTEND but these all only target a
> single arch.
>
> Part of me tries to ensure whatever solution we come up with can scale.
> This means I'd like my arm target to be able to build compilers
> targetting x86, mips and ppc as well as arm, all in one build. The
> question then comes to libc and whether you'd rebuild libc each time,
> whether you'd reuse the same libc package as a standard build or whether
> you'd have a special version of the libc for the 'target-cross-canadian'
> toolchain.
There is definitely quite a bit of madness in getting oe to build
additional toolchains even for the same architecture, let alone
different architectures. ;)
I have been playing around with getting a baremetal toolchain to build
alongside the linux one, it seemed like a good place to start before
diving into additional arch, cross-canadian builds. With the
BBCLASSEXTEND stuff, I have gotten a fair way into the process of
having a class providing overrides to the gcc-*/binutils-* recipes to
allow for bitbake to build a secondary baremetal (with newlib)
toolchain alongside the default machine/target toolchain. There are
however changes that I needed to make to the recipes to make them m
Re: [yocto] Cross compiler which runs on the target architecture.
Hi Richard,
Thanks for the samples.
I have been taking a slightly different approach. It seems to me that
poky/cross-canadian.bbclass is very specific to SDK generation, and
could almost be called cross-canadian-sdk.bbclass where the sdk reflects
the choice of host architecture. There are four architectures to
consider (build, host, target and crosstarget) so my
cross-canadian-target.bbclass is intended to have build set to the build
machine, host set to the target and then target set to whatever
crosstarget is configured with. Not got very far with this yet but that
is the plan and I await with interest to see what problems I get when
cross compiling the version of gcc!
I guess the problem is that so many of the scripts like
autotools.bbclass use variables specific to a particular configuration
(--target=${TARGET_SYS}) rather than using internal generic variables
that are assigned by the layer that uses the class. Thus
autotools.bbclass could use autotools_target_sys that gets configured by
the calling layer and thus avoiding having to apply replace patches like:
replace('CONFIGUREOPTS', '--target=${TARGET_SYS}','--target=avr', d)
or
HOST_SYS := "${TARGET_SYS}"
TARGET_SYS = "avr"
Far better if the layers were based on a four architecture model (build,
host, target and crosstarget) with at least some of the core classes
avoiding specific configurations.
Anyway as I said thank you for your input and have a good Christmas and
New Year!
Peter
On 23/12/14 12:49, Nathan Rossi wrote:
On Tue, Dec 23, 2014 at 12:53 AM, Richard Purdie
wrote:
Hi,
On Sat, 2014-12-20 at 14:43 +, Peter Saunderson wrote:
I have seen a brief IRC chat
(https://www.yoctoproject.org/irc/%23yocto.2013-09-23.log.html talking
about https://github.com/nathanrossi/meta-parallella) about this
question but nothing much else so this is an attempt to get more public
feedback on this request.
That was me, as you might have noticed I ended up for now just using a
pre-built toolchain that was copied into the system image with a
recipe. This works but its not ideal.
There have been a few threads recently regarding similar functionality desires:
* https://lists.yoctoproject.org/pipermail/yocto/2014-December/022751.html
* https://lists.yoctoproject.org/pipermail/yocto/2014-December/022653.html
(this one is more about multi-machine builds, but still relevant)
I am trying to build a cross compiler that runs on the target processor
and a cross compiler that runs on the host processor so that I can build
code for a third processor (Epiphany). If you want examples of the
traditional way to build this compiler look at
https://github.com/adapteva/epiphany-sdk epiphany-gcc epiphany-newlib
epiphany-binutils... The end result would be a set of recipes that run
on a pc build machine that build both arm code for the interim target
and epiphany code for the final target and provides an SDK for the pc
that enables you to cross compile for both arm and epiphany.
I have been interested in this myself for the epiphany case as well as
a few additional cases (from a personal interest as well as for
Xilinx/meta-xilinx):
* epiphany native, nativesdk and target cross compilers
* baremetal toolchain (using newlib)
* canadian-cross arch baremetal (e.g. arm host building for
microblaze baremetal)
* and also (canadian-)cross arch linux
As I am just starting to look at this I would like to know what size of
task I am up against! My initial efforts based on review of
poky/meta/recipes-devtools/binutils etc seem to suggest that I have to
modify at least ${HOST_PREFIX}, ${TARGET_PREFIX}, ${TARGET_ARCH} etc for
my epiphany-??? recipes so that the I can install the compiler in a
suitable location with a suitable prefix, the IRC chat indicates that
there are more things to consider also.
The question I have is about how easy it will be to use existing recipes
for existing compiler / binutils etc... or is this likely to end up as a
completely new set of recipes from the ground up because the existing
recipes cant cope with building cross / cross compilers where there are
three processors to consider (host (intel based pc), interim target
(arm) and final target (epiphany)), or at least a lot of changes in the
existing recipes to cope with something like TARGET_TARGET_ARCH =
${TARGET_ARCH}_${FINAL_TARGET_ARCH}??
Funnily enough I've a similar need to do something like this for a
personal project but targeting AVR.
Certainly OE has the power and capability to do something like this, I'm
not sure its straightforward though, at least generically, and I say
that as one of the people with pretty intimate knowledge of the
toolchain recipes.
The easy parts are creating recipes for binutils and gcc to run on the
target, targeting a third arch. This is like cross-canadian but built to
run on MACHINE instead of SDKMACHINE and taretting a new arch (probably
'target-cross-canadian'). The massively harder part is the libc for gcc
to b
Re: [yocto] autobuilder: How to set PREMIRRORS?
Elizabeth,
Thanks for the tips. I think I have something close to working, just need to
finish testing. I should have a patch for you the first week of January.
Thanks,
Bryan E.
> -Original Message-
> From: Flanagan, Elizabeth [mailto:elizabeth.flana...@intel.com]
> Sent: Tuesday, December 16, 2014 3:14 PM
> To: Bryan Evenson
> Cc: yocto@yoctoproject.org
> Subject: Re: autobuilder: How to set PREMIRRORS?
>
> 2014-11-19 15:12 GMT+00:00 Bryan Evenson :
> > All,
> >
> > I'm getting close to implementing this feature, but I'm having some issues
> getting auto.conf formatted correctly. See below.
> >
> >> -Original Message-
> >> From: Bryan Evenson
> >> Sent: Monday, November 17, 2014 9:08 AM
> >> To: Bryan Evenson; yocto@yoctoproject.org;
> elizabeth.flana...@intel.com
> >> Subject: RE: autobuilder: How to set PREMIRRORS?
> >>
> >> All,
> >>
> >> After looking through the autobuilder code, I don't see anywhere in which
> >> PREMIRRORS can be set and used. I see in CreateAutoConf.py that
> >> PREMIRRORS is always set to "". I don't think it'd be that difficult to
> >> add
> >> PREMIRRORS as a CreateAutoConf parameter for the buildsets. I can
> work
> >> on the change and submit the patch. But before I start I have a few
> >> questions:
> >>
> >> 1. I plan on implementing the PREMIRRORS parameter as an array, similar
> to
> >> 'layerdirs' for CreateBBLayersConf. For example:
> >>
> >> {'CreateAutoConf' : {'PREMIRRORS' : ['git://.*/.*
> >> http://our/local/mirror/path/mirror/sources/ ',
> >> 'ftp://.*/.* http://our/local/mirror/path /mirror/sources/ ',
> >> 'http://.*/.* http://our/local/mirror/path/mirror/sources/ ',
> >> 'https://.*/.* http://our/local/mirror/path/mirror/sources/ ']}
> >>
> >> would add the following to auto.conf:
> >>
> >> PREMIRRORS = 'git://.*/.* http://our/local/mirror/path/mirror/sources/
> \
> >> ftp://.*/.* http://our/local/mirror/path /mirror/sources/ \
> >> http://.*/.* http://our/local/mirror/path/mirror/sources/ \
> >> https://.*/.* http://our/local/mirror/path/mirror/sources/ '
> >>
> >> Does this sound reasonable, or would a different parameter format be
> >> preferred?
> >
>
> I would actually do this similar to how we have DEVKERNEL_MUT_REPO.
>
> PREMIRRORS = ['git://.*/.*
> http://our/local/mirror/path/mirror/sources/', 'ftp://.*/.*
> http://our/local/mirror/path /mirror/sources/', 'http://.*/.*
> http://our/local/mirror/path/mirror/sources/', 'https://.*/.*
> http://our/local/mirror/path/mirror/sources/']
>
> > I am trying to add a single PREMIRROR using the syntax I specified above.
> At this time it is getting inserted in auto.conf. However, the system is
> going
> into an infinite loop building the PREMIRROR path. The added content to
> auto.conf at this time looks like:
> >
> > PREMIRRORS = " \
> > http://.*.* http://server.repo.local/mirror/sources/ \n \
> > "
> >
> > And from looking at log.do_fetch for the package that attempts to use the
> PREMIRROR, the log is filled with
> "server.repo.localserver.repo.localserver.repo.local" repeating. Any tips on
> how PREMIRRORS should be built?
> >
> > Here's what I have so far in CreateAutoConf.py:
> >
> > self.PREMIRRORS=""
> > fout = fout + 'PREMIRRORS = " \ \n'
> > if list(self.PREMIRRORS):
> > for premirror in self.PREMIRRORS:
> > fout = fout + premirror + ' n \ \n'
> > fout = fout + '" \n'
> >
> > Any tips on how to change things so PREMIRRORS is correctly parsed?
> >
>
> #make sure you add
> #
> #export PREMIRRORS=""
> # to yocto-autobuilder-setup
>
> if os.environ.get('PREMIRRORS') is not None:
> premirrors=ast.liternal_eval(os.environ.get('PREMIRRORS').encode('utf-8')
> fout =+ 'PREMIRRORS = "\ \n'
> for mirror in premirrors:.
>
> I think this should do what you're looking for.
>
> > Thanks,
> > Bryan
> >
>
> --
> Elizabeth Flanagan
> Yocto Project
> Build and Release
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RFC - enable toaster on the autobuilder
Hi Beth, The bitbake patchset was merged last week, and I've made the requested changes to the autobuilder patchset. Can you please review and pull *poky-contrib: adamian/autobuilder-enable-toaster *at your convenience ? Thanks, Alex On Wed, Dec 10, 2014 at 11:13 AM, Damian, Alexandru < alexandru.dam...@intel.com> wrote: > Hi, > > Thanks for the quick reply - > > yes, Toaster needs buildhistory; it also needs the "toaster" bbclass in > the INHERIT list. > > I'll make the changes and re-submit. > > Cheers, > Alex > > On Tue, Dec 9, 2014 at 6:07 PM, Flanagan, Elizabeth < > elizabeth.flana...@intel.com> wrote: > >> A few initial comments. >> >> TOASTER_UPLOADURL needs to be added to >> config/autobuilder.conf.example. It would also be nice if it was added >> to docs. Please set it to a localhost URL and comment it out for the >> time being. >> >> Also, can we make it TOASTER_UPLOAD_URL. It matches my naming >> convention for config strings a bit closer. >> >> If toaster needs buildhistory, I'm going to have to do some work on >> getting buildhistory to setup automatically on an autobuilder install >> (or at least document how to do it). >> >> -b >> >> On Tue, Dec 9, 2014 at 8:42 AM, Damian, Alexandru >> wrote: >> > Hello, >> > >> > I'm sending a patchset to enable Toaster logging for the autobuilder - >> can >> > you please review and comment ? >> > >> > I have pending Bitbake patchset (poky-contrib:adamian/devel-settings) >> > Bitbake that adds two toaster-on-autobuilder related features: >> > 1. build event logging flag (-w) will write an UI event log file >> > 2. toaster end point that receives a log file over a HTTP POST request >> and >> > loads the data in the toaster database >> > >> > Based on this approach, I've created an autobuilder patchset that >> enables 1. >> > at all times, and 2. uploads the data to a Toaster server if such >> server is >> > specified in the build configuration >> > >> > Can you please review: >> > >> > poky-contrib: adamian/autobuilder-enable-toaster >> > >> > >> > Thanks, >> > Alex >> > >> > -- >> > Alex Damian >> > Yocto Project >> > SSG / OTC >> > >> > - >> > Intel Corporation (UK) Limited >> > Registered No. 1134945 (England) >> > Registered Office: Pipers Way, Swindon SN3 1RJ >> > VAT No: 860 2173 47 >> > >> > This e-mail and any attachments may contain confidential material for >> > the sole use of the intended recipient(s). Any review or distribution >> > by others is strictly prohibited. If you are not the intended >> > recipient, please contact the sender and delete all copies. >> >> >> >> -- >> Elizabeth Flanagan >> Yocto Project >> Build and Release >> > > > > -- > Alex Damian > Yocto Project > SSG / OTC > -- Alex Damian Yocto Project SSG / OTC -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Setting up an init other than SysVinit or systemd?
All, I am in the process of upgrading core items in my image (core-image-minimal with a few additional packages), and one item I am taking a look at is changing my init from SysVinit. I know the other easily supported option for init is systemd, but if I change to systemd I want to do it because it works best for my setup and not just because I think its my only other option. I'd like to try some other init options out, but I don't see how to setup the configuration to use an init other than SysVinit or systemd and I am looking for some help. >From looking at the OpenEmbedded Metadata Index, I see there is a recipe for >Upstart (http://layers.openembedded.org/layerindex/recipe/4994/) so I'm >assuming somone else has used Upstart at least at one time. I also know that >Busybox includes runit. I'd like to give each of these a try to see how they >work, but first I need to build an image with these init managers. From >looking at the development manual I see how to choose systemd but I don't see >how to choose anything else. What configuration variables do I need to set in order to use a different init system? What items do I need to add that are automatically added when using SysVInit or systemd that would not be added when using an unsupported init system? Thanks, Bryan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building clang with Yocto
Hi Chan, The errors that you are experiencing point to a mismatch between the target architecture of the compiler, and the headers and libraries that the compiler finds. There are several steps that are necessary to get right before you can produce correct code with the compiler. 1. Configure the clang compiler build such that the compiler will be built to execute on the architecture of the workstation you that you intend to use to compile code for your target with clang. 2. Configure the clang compiler build such that the clang compiler will support code generation for the architecture of the target machine. 3. Modify a copy of the environment-setup file in /opt/poky/... to Here's a page which explains cross compilation using clang. http://clang.llvm.org/docs/CrossCompilation.html Here's an excerpt that talks about specifying the target triple which defines the target architecture that the clang compiler will produce code for: *** Target Triple The basic option is to define the target architecture. For that, use -target . If you don’t specify the target, CPU names won’t match (since Clang assumes the host triple), and the compilation will go ahead, creating code for the host platform, which will break later on when assembling or linking. The triple has the general format ---, where: arch = x86, arm, thumb, mips, etc. sub = for ex. on ARM: v5, v6m, v7a, v7m, etc. vendor = pc, apple, nvidia, ibm, etc. sys = none, linux, win32, darwin, cuda, etc. abi = eabi, gnu, android, macho, elf, etc. The sub-architecture options are available for their own architectures, of course, so “x86v7a” doesn’t make sense. The vendor needs to be specified only if there’s a relevant change, for instance between PC and Apple. Most of the time it can be omitted (and Unknown) will be assumed, which sets the defaults for the specified architecture. The system name is generally the OS (linux, darwin), but could be special like the bare-metal “none”. When a parameter is not important, they can be omitted, or you can choose unknown and the defaults will be used. If you choose a parameter that Clang doesn’t know, like blerg, it’ll ignore and assume unknown, which is not always desired, so be careful. Finally, the ABI option is something that will pick default CPU/FPU, define the specific behaviour of your code (PCS, extensions), and also choose the correct library calls, etc. I hope that you find this helpful. -Jim- From: Yu, Chan KitX [chan.kitx...@intel.com] Sent: Tuesday, December 23, 2014 1:21 AM To: Paul Eggleton Cc: Jim Rafert; yocto@yoctoproject.org Subject: Re: [yocto] Building clang with Yocto I tried ldd-ing my binary on my build machine since it doesn't work on my image and it was built on glibc indeed. Since yocto is based on ulibc so it won't work even my target platform is roughly the same as my build platform. I wonder what options should I specify to get llvm to build against the Yocto's libraries rather than my build machine's. As I said in IRC yesterday I found https://lists.yoctoproject.org/pipermail/yocto/2014-June/020358.html which should suit my needs but I get stupid errors on uint32_t: /work/corei7-64-poky-linux/llvm/3.3-r0/llvm -3.3.src/include/llvm/Support/BranchProbability.h:27:3: error: 'uint32_t' does not name a type uint32_t N; I tried adding #include to that header but no luck. -Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Sent: Monday, December 22, 2014 7:22 PM To: Yu, Chan KitX Cc: 'Liviu Gheorghisan'; 'Jim Rafert'; yocto@yoctoproject.org Subject: Re: [yocto] Building clang with Yocto Hi Chan Kit, On Monday 22 December 2014 03:33:17 Yu, Chan KitX wrote: > Here's an update FYI. I have managed to get clang sort of working. It > compiles my sample code but I can't get the binary to execute. ./a.out > simply returns: > > > ./a.out: No such file or directory. > > I'm sure that a.out exists and weirdly I could get the same binary > file to run on my build machine. So I guess it could be because of > some architecture difference but both target and build platform are > quite the same (Intel x64 in build machine and BayleyBay for target > platform) I used > valleyisland-64 for the target platform so both should be able to > execute > 64 bit binaries. I suppose I can specify some other configuration > options there but I have no idea what to specify the configure > parameter --target= . x64 did not do any good. So any idea? That sounds a bit like the binary has been linked to libraries in the host libdir rather than the correct one for the target. You may be able to verify that using ldd. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https
[yocto] 1.8_M1 released
The first milestone release for the upcoming Yocto Project 1.8 release is now available at: http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-1.8_M1/ Thank you everyone for all your contributions. eclipse-poky-juno 26bfc407781aa185f244a47ba63120343cee4a37 eclipse-poky-kepler b4d75601847b4c5b060265a37b47c2a9642da62d meta-fsl-arm a593ac48d1a13067d3e4000be616e34699ea4732 meta-fsl-ppc 486a72425f2f6e25efd9bfdbb9638fb58e90a85f meta-intel a72da6350e7a77256ad597e8e8c40909590a2a40 meta-minnow 13a5f2ab84c7284647a3e067a33109c11dae0568 meta-qt3 3016129d90b7ac8517a5227d819f10ad417b5b45 poky b813bdebb36501500e86fea5f7e15b4b15ea0902 -- Elizabeth Flanagan Yocto Project Build and Release -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RFC - enable toaster on the autobuilder
On 23 December 2014 at 07:20, Damian, Alexandru wrote: > Hi Beth, > > The bitbake patchset was merged last week, and I've made the requested > changes to the autobuilder patchset. Sure, this will probably not be until during the holidays (26thish or so). > > Can you please review and pull poky-contrib: > adamian/autobuilder-enable-toaster at your convenience ? > > Thanks, > Alex > > On Wed, Dec 10, 2014 at 11:13 AM, Damian, Alexandru > wrote: >> >> Hi, >> >> Thanks for the quick reply - >> >> yes, Toaster needs buildhistory; it also needs the "toaster" bbclass in >> the INHERIT list. >> >> I'll make the changes and re-submit. >> >> Cheers, >> Alex >> >> On Tue, Dec 9, 2014 at 6:07 PM, Flanagan, Elizabeth >> wrote: >>> >>> A few initial comments. >>> >>> TOASTER_UPLOADURL needs to be added to >>> config/autobuilder.conf.example. It would also be nice if it was added >>> to docs. Please set it to a localhost URL and comment it out for the >>> time being. >>> >>> Also, can we make it TOASTER_UPLOAD_URL. It matches my naming >>> convention for config strings a bit closer. >>> >>> If toaster needs buildhistory, I'm going to have to do some work on >>> getting buildhistory to setup automatically on an autobuilder install >>> (or at least document how to do it). >>> >>> -b >>> >>> On Tue, Dec 9, 2014 at 8:42 AM, Damian, Alexandru >>> wrote: >>> > Hello, >>> > >>> > I'm sending a patchset to enable Toaster logging for the autobuilder - >>> > can >>> > you please review and comment ? >>> > >>> > I have pending Bitbake patchset (poky-contrib:adamian/devel-settings) >>> > Bitbake that adds two toaster-on-autobuilder related features: >>> > 1. build event logging flag (-w) will write an UI event log file >>> > 2. toaster end point that receives a log file over a HTTP POST request >>> > and >>> > loads the data in the toaster database >>> > >>> > Based on this approach, I've created an autobuilder patchset that >>> > enables 1. >>> > at all times, and 2. uploads the data to a Toaster server if such >>> > server is >>> > specified in the build configuration >>> > >>> > Can you please review: >>> > >>> > poky-contrib: adamian/autobuilder-enable-toaster >>> > >>> > >>> > Thanks, >>> > Alex >>> > >>> > -- >>> > Alex Damian >>> > Yocto Project >>> > SSG / OTC >>> > >>> > - >>> > Intel Corporation (UK) Limited >>> > Registered No. 1134945 (England) >>> > Registered Office: Pipers Way, Swindon SN3 1RJ >>> > VAT No: 860 2173 47 >>> > >>> > This e-mail and any attachments may contain confidential material for >>> > the sole use of the intended recipient(s). Any review or distribution >>> > by others is strictly prohibited. If you are not the intended >>> > recipient, please contact the sender and delete all copies. >>> >>> >>> >>> -- >>> Elizabeth Flanagan >>> Yocto Project >>> Build and Release >> >> >> >> >> -- >> Alex Damian >> Yocto Project >> SSG / OTC > > > > > -- > Alex Damian > Yocto Project > SSG / OTC > > - > Intel Corporation (UK) Limited > Registered No. 1134945 (England) > Registered Office: Pipers Way, Swindon SN3 1RJ > VAT No: 860 2173 47 > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. -- Elizabeth Flanagan Yocto Project Build and Release -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [ANNOUNCEMENT] Intel(R) Valley Island BSP for Yocto 1.6.2 "dizzy"
All, We are pleased to announce the updated release of the Intel® Valley Island BSP for the Yocto Project "daisy" 1.6.2 release. https://www.yoctoproject.org/downloads/bsps/daisy162/valley-island-64-bit Supported Platforms: - Bayley Bay CRB - Bakersport CRB - Valley Island Development Kit - MinnowBoard Max Features Supported in this Release: --- - Linux kernel version 3.10-LTSI - Support integrated graphics (i915) - Support SATA, USB v2.0 & v3.0 Host, USB device mode (Bakersport only), eMMC and SD Host Controller, GbE, HD Audio, APIC, RTC. - Support LPSS I/O devices - SPI, HSUART, I2C, GPIO, SMBus i801, Serial 8250, PWM - Support LPSS device enumeration in both PCI and ACPI mode. Miscellaneous - This BSP was built with the following commit id for valleyisland machine: poky/daisy: e3dd621197548b4cf64988e757e9bc926082db73 meta-intel/daisy: 39cdd2fa13bc387388bcf5f07b8ee4c45f3f2135 32-bit image was built with the following commit id for valleyisland machine: linux-yocto ver3.10 machine branch: standard/base: 747e1cbd12b15db8bc2ae86e2359c1b113f120d6 linux-yocto ver3.10 meta branch : meta: 8f05306a8e6f5ee422d50c3317acce0cf9e6aada linux-yocto ver3.10 feature branch: valleyisland-io-3.0:0992d01f5f382f6da60004ef87f67ebd3ca13732 64-bit image was built with the following commit id for valleyisland machine: linux-yocto ver3.10 machine branch: standard/base:standard/base: 747e1cbd12b15db8bc2ae86e2359c1b113f120d6 linux-yocto ver3.10 meta branch : meta: 8f05306a8e6f5ee422d50c3317acce0cf9e6aada linux-yocto ver3.10 feature branch: valleyisland-io-3.0:0992d01f5f382f6da60004ef87f67ebd3ca13732 -- Elizabeth Flanagan Intel Corp. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building clang with Yocto
Question: Does the fact that Yocto is based on elibc rather than libc be the cause of the incompatibility here? -Original Message- From: Jim Rafert [mailto:j...@spectralogic.com] Sent: Wednesday, December 24, 2014 12:58 AM To: Yu, Chan KitX; Paul Eggleton Cc: yocto@yoctoproject.org Subject: RE: [yocto] Building clang with Yocto Hi Chan, The errors that you are experiencing point to a mismatch between the target architecture of the compiler, and the headers and libraries that the compiler finds. There are several steps that are necessary to get right before you can produce correct code with the compiler. 1. Configure the clang compiler build such that the compiler will be built to execute on the architecture of the workstation you that you intend to use to compile code for your target with clang. 2. Configure the clang compiler build such that the clang compiler will support code generation for the architecture of the target machine. 3. Modify a copy of the environment-setup file in /opt/poky/... to Here's a page which explains cross compilation using clang. http://clang.llvm.org/docs/CrossCompilation.html Here's an excerpt that talks about specifying the target triple which defines the target architecture that the clang compiler will produce code for: *** Target Triple The basic option is to define the target architecture. For that, use -target . If you don't specify the target, CPU names won't match (since Clang assumes the host triple), and the compilation will go ahead, creating code for the host platform, which will break later on when assembling or linking. The triple has the general format ---, where: arch = x86, arm, thumb, mips, etc. sub = for ex. on ARM: v5, v6m, v7a, v7m, etc. vendor = pc, apple, nvidia, ibm, etc. sys = none, linux, win32, darwin, cuda, etc. abi = eabi, gnu, android, macho, elf, etc. The sub-architecture options are available for their own architectures, of course, so "x86v7a" doesn't make sense. The vendor needs to be specified only if there's a relevant change, for instance between PC and Apple. Most of the time it can be omitted (and Unknown) will be assumed, which sets the defaults for the specified architecture. The system name is generally the OS (linux, darwin), but could be special like the bare-metal "none". When a parameter is not important, they can be omitted, or you can choose unknown and the defaults will be used. If you choose a parameter that Clang doesn't know, like blerg, it'll ignore and assume unknown, which is not always desired, so be careful. Finally, the ABI option is something that will pick default CPU/FPU, define the specific behaviour of your code (PCS, extensions), and also choose the correct library calls, etc. I hope that you find this helpful. -Jim- From: Yu, Chan KitX [chan.kitx...@intel.com] Sent: Tuesday, December 23, 2014 1:21 AM To: Paul Eggleton Cc: Jim Rafert; yocto@yoctoproject.org Subject: Re: [yocto] Building clang with Yocto I tried ldd-ing my binary on my build machine since it doesn't work on my image and it was built on glibc indeed. Since yocto is based on ulibc so it won't work even my target platform is roughly the same as my build platform. I wonder what options should I specify to get llvm to build against the Yocto's libraries rather than my build machine's. As I said in IRC yesterday I found https://lists.yoctoproject.org/pipermail/yocto/2014-June/020358.html which should suit my needs but I get stupid errors on uint32_t: /work/corei7-64-poky-linux/llvm/3.3-r0/llvm -3.3.src/include/llvm/Support/BranchProbability.h:27:3: error: 'uint32_t' does not name a type uint32_t N; I tried adding #include to that header but no luck. -Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Sent: Monday, December 22, 2014 7:22 PM To: Yu, Chan KitX Cc: 'Liviu Gheorghisan'; 'Jim Rafert'; yocto@yoctoproject.org Subject: Re: [yocto] Building clang with Yocto Hi Chan Kit, On Monday 22 December 2014 03:33:17 Yu, Chan KitX wrote: > Here's an update FYI. I have managed to get clang sort of working. It > compiles my sample code but I can't get the binary to execute. ./a.out > simply returns: > > > ./a.out: No such file or directory. > > I'm sure that a.out exists and weirdly I could get the same binary > file to run on my build machine. So I guess it could be because of > some architecture difference but both target and build platform are > quite the same (Intel x64 in build machine and BayleyBay for target > platform) I used > valleyisland-64 for the target platform so both should be able to > execute > 64 bit binaries. I suppose I can specify some other configuration > options there but I have no idea what to specify the configure > parameter --target= . x64 did not do any good. S
