[yocto] native recipe question
Hi, I'm having to build a package (arrayfire) for Tegra. This package requires to first build a x86_64 utility (bin2cpp) which is then used for building the tegra arrayfire. Do I understand correctly that I should create: - arrayfire-native.bb: for compiling the x86_64 utility. If so how do I instruct the platform? - arrayfire.bb: for compiling the tegra platform. This recipe requires arrayfire-native.bb and I should get a copy in the recipe-sysroot-native folder? Thanks -Damien -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ldd
Hi! When searching for "yocto ldd" Google brings up this old posting On Mon Nov 11 05:25:08 PST 2013 Chris Hallinan challinan at gmail.com wrote: > On Sat, Nov 9, 2013 at 9:57 AM, Gary Thomas wrote: > >> On 2013-11-09 06:42, Seth Bollinger wrote: >> >>> Hello All, >>> >>> I don't see that ldd is part of the cross toolchain build anywhere. Am I >>> missing something? >>> >> >> It's built with the eglibc recipe and is packaged separately. >> >> Right, and the command to locate it is $ oe-pkgdata-util find-path /usr/bin/ldd ldd: /usr/bin/ldd So the package name is indeed ldd. >Gosh, I though ldd, originally a hard-to-maintain script, was obsoleted a >long time ago. This command: > >$ readelf --dynamic > >provides the same information, and readelf can be found in every cross >toolchain. > >-Chris > I don't think that is correct. readelf only shows static information embedded into the binary. ldd does runtime lookup obeying e.g. the LD_LIBRARY_PATH environment variable. It also has options -r and -u for actually doing the relocations and it will report errors if they don't succeed. So ldd is more useful than readelf for some use cases. Regards, Uwe Geuder Neuro Event Labs Oy Tampere, Finland uwe.gex...@neuroeventlabs.com (Bot check: fix one obvious typo) -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] populate_sdk in image class
A long time ago the image class got an inherit to the populate_sdk* class which brings a lot of dependencies on python modules. Is it strictly necessary that to build an image, i need to satisfy nativesdk-libgcc among others? Is there not a performance and complexity impact? I never needed to use the nativesdk separately as "the primary way of running builds within the extensible SDK is to use the 'devtool' command" (quote from SHA1 545673). Should not this class inheritance be moved into devtool or at least make the dependencies be triggered with the do_populate_sdk* task? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] native recipe question
On 22 May 2018 at 08:43, Damien LEFEVRE wrote:
> I'm having to build a package (arrayfire) for Tegra. This package requires
> to first build a x86_64 utility (bin2cpp) which is then used for building
> the tegra arrayfire.
>
> Do I understand correctly that I should create:
>
> arrayfire-native.bb: for compiling the x86_64 utility. If so how do I
> instruct the platform?
> arrayfire.bb: for compiling the tegra platform. This recipe requires
> arrayfire-native.bb and I should get a copy in the recipe-sysroot-native
> folder?
That's one solution, but if it's jus a single tool that you need built
then you can build that yourself using the host compiler. The best
practise here is for the upstream build to respect CC_FOR_BUILD ("use
this compiler to build binaries that I need to run at build time")
which we already export. As presumably arrayfire doesn't do this,
then you can just build it yourself first. For example, the Pango
recipe in oe-core basically does this:
do_compile_prepend_class-target () {
make CC="${BUILD_CC}" LDFLAGS="${BUILD_LDFLAGS}" -C
${B}/tests gen-all-unicode
}
Which makes it build tests/gen-all-unicode using BUILD_CC (host
compiler, not cross compiler) for target builds before it goes and
builds the rest of the project.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] native recipe question
Thanks that did the trick.
I actually needed to add the tool compilation in do_configure_prepend
because the cmake configuration requires the output folder for bin2cpp.
Just out of completeness. I had created that arrayfire-native recipe and it
looked like this:
BBCLASSEXTEND = "native"
SRC_URI = "gitsm://
github.com/arrayfire/arrayfire.git;protocol=https;branch=v3.6"
SRCREV = "ee21c791d5af4fa56bca168804ba1597cf9d6503"
PR="r0"
S = "${WORKDIR}/git"
inherit cmake cuda
do_configure(){
cd ${B}
cmake ${S} \
-DAF_BUILD_CPU=OFF \
-DAF_BUILD_CUDA=OFF \
-DAF_BUILD_OPENCL=OFF \
-DAF_BUILD_EXAMPLES=OFF \
-DAF_BUILD_TEST=OFF \
-DAF_WITH_GRAPHICS=OFF \
-DCMAKE_BUILD_TYPE=Release
}
do_compile(){
make bin2cpp
}
do_install() {
install -d ${D}/${bindir}
install -m 755 ${WORKDIR}/build/bin2cpp ${D}${bindir}
}
# Defining packages
FILES_${PN} = "${bindir}/*"
The recipe builds. When I try using with DEPENDS += "arrayfire-native" in
the arrayfire recipe I get this warning:
WARNING: arrayfire-3.6.0-r0 do_prepare_recipe_sysroot: Manifest
/home/damien/pyro/build-jetson-tx2/tmp/sstate-control/manifest-x86_64-arrayfire-native.populate_sysroot
not found?
and
/home/damien/pyro/build-jetson-tx2/tmp/work/aarch64_tegra186-poky-linux/arrayfire/3.6.0-r0/recipe-sysroot-native
did not contain the bin2cpp binary.
What did I miss?
Thanks
On Tue, May 22, 2018 at 12:19 PM, Burton, Ross
wrote:
> On 22 May 2018 at 08:43, Damien LEFEVRE wrote:
> > I'm having to build a package (arrayfire) for Tegra. This package
> requires
> > to first build a x86_64 utility (bin2cpp) which is then used for building
> > the tegra arrayfire.
> >
> > Do I understand correctly that I should create:
> >
> > arrayfire-native.bb: for compiling the x86_64 utility. If so how do I
> > instruct the platform?
> > arrayfire.bb: for compiling the tegra platform. This recipe requires
> > arrayfire-native.bb and I should get a copy in the recipe-sysroot-native
> > folder?
>
> That's one solution, but if it's jus a single tool that you need built
> then you can build that yourself using the host compiler. The best
> practise here is for the upstream build to respect CC_FOR_BUILD ("use
> this compiler to build binaries that I need to run at build time")
> which we already export. As presumably arrayfire doesn't do this,
> then you can just build it yourself first. For example, the Pango
> recipe in oe-core basically does this:
>
> do_compile_prepend_class-target () {
> make CC="${BUILD_CC}" LDFLAGS="${BUILD_LDFLAGS}" -C
> ${B}/tests gen-all-unicode
> }
>
> Which makes it build tests/gen-all-unicode using BUILD_CC (host
> compiler, not cross compiler) for target builds before it goes and
> builds the rest of the project.
>
> Ross
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] native recipe question
On 22 May 2018 at 11:56, Damien LEFEVRE wrote: > The recipe builds. When I try using with DEPENDS += "arrayfire-native" in > the arrayfire recipe I get this warning: > WARNING: arrayfire-3.6.0-r0 do_prepare_recipe_sysroot: Manifest > /home/damien/pyro/build-jetson-tx2/tmp/sstate-control/manifest-x86_64-arrayfire-native.populate_sysroot > not found? Don't call the recipe arrayfire-native and then BBCLASSEXTEND=native, as you'll end up with a non-native arrayfile-native and a native arrayfire-native-native... Either have a minimal arrayfire-native recipe which inherits native and just builds the piece you want, or do the prepend in the recipe as I said. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] native recipe question
OK I got it now. Thanks! On Tue, May 22, 2018 at 2:00 PM, Burton, Ross wrote: > On 22 May 2018 at 11:56, Damien LEFEVRE wrote: > > The recipe builds. When I try using with DEPENDS += "arrayfire-native" > in > > the arrayfire recipe I get this warning: > > WARNING: arrayfire-3.6.0-r0 do_prepare_recipe_sysroot: Manifest > > /home/damien/pyro/build-jetson-tx2/tmp/sstate-control/ > manifest-x86_64-arrayfire-native.populate_sysroot > > not found? > > Don't call the recipe arrayfire-native and then BBCLASSEXTEND=native, > as you'll end up with a non-native arrayfile-native and a native > arrayfire-native-native... > > Either have a minimal arrayfire-native recipe which inherits native > and just builds the piece you want, or do the prepend in the recipe as > I said. > > Ross > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-swupd][PATCH] layer.conf: add LAYERSERIES_COMPAT
From: André Draszik This layer is compatible with pyro and sumo/master (both tested), and hence should also be compatible with rocko (untested). Signed-off-by: André Draszik --- conf/layer.conf | 2 ++ 1 file changed, 2 insertions(+) diff --git a/conf/layer.conf b/conf/layer.conf index 50e7558..16b1832 100644 --- a/conf/layer.conf +++ b/conf/layer.conf @@ -11,6 +11,8 @@ BBFILE_PRIORITY_meta-swupd = "6" LAYERVERSION_meta-swupd = "1" +LAYERSERIES_COMPAT_meta-swupd = "pyro rocko sumo" + SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "\ oe-swupd-helpers->bash \ oe-swupd-helpers->busybox \ -- 2.17.0 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto SDK & Toolchain Deploy Issue
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
Re: [yocto] Yocto SDK & Toolchain Deploy Issue
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
[yocto] [meta-selinux][master][rocko][PATCH] selinux-image: fix labeling on non-seclabel mounts
Use -m to prevent non-seclabel mounts from being excluded from labeling.
After the following commit setfiles will no longer label files on a
mount other than / if it doesn't have seclabel listed in /proc/mounts:
https://github.com/SELinuxProject/selinux/commit/f2e77865e144ab2e1313aa78d99b969f8f48695e#diff-2de9aefdd8fc5bc6a8740533e5d1cc2e
Signed-off-by: George McCollister
---
classes/selinux-image.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/classes/selinux-image.bbclass b/classes/selinux-image.bbclass
index 90ead2f..5174dc5 100644
--- a/classes/selinux-image.bbclass
+++ b/classes/selinux-image.bbclass
@@ -1,6 +1,6 @@
selinux_set_labels () {
POL_TYPE=$(sed -n -e
"s&^SELINUXTYPE[[:space:]]*=[[:space:]]*\([0-9A-Za-z_]\+\)&\1&p"
${IMAGE_ROOTFS}/${sysconfdir}/selinux/config)
-if ! setfiles -r ${IMAGE_ROOTFS}
${IMAGE_ROOTFS}/${sysconfdir}/selinux/${POL_TYPE}/contexts/files/file_contexts
${IMAGE_ROOTFS}
+if ! setfiles -m -r ${IMAGE_ROOTFS}
${IMAGE_ROOTFS}/${sysconfdir}/selinux/${POL_TYPE}/contexts/files/file_contexts
${IMAGE_ROOTFS}
then
echo WARNING: Unable to set filesystem context, setfiles / restorecon
must be run on the live image.
touch ${IMAGE_ROOTFS}/.autorelabel
--
2.16.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] busybox / sysklogd post install conflict
I have run into an issue building against sumo branch (using opkg if that matters). This patch removed the update-alternatives for sysklogd. https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=c83eb10f70b714ce3a8c165fad547d800f3ed27d However, busybox is still configured with syslog support. The script that generates all of the symlinks for busybox runs during the main busybox package post install. This causes the post install to exit with an error since it can't create the links for klogd and syslogd if sysklogd is installed without update alternatives. >From busybox.postinst: update-alternatives --install /sbin/klogd klogd /bin/busybox.nosuid 50 update-alternatives --install /sbin/syslogd syslogd /bin/busybox.nosuid 50 I think that patch needs to be reverted. The rconflicts for busybox-syslog and sysklogd takes care of the conflicting config file name that is shared between the two packages but we still need the update-alternatives. Unless the function that generates the busybox symlinks gets smart enough to generate the symlinks only in the busybox-syslog package. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Release Candidate Build for yocto-2.3.4.rc1 now available.
A release candidate build for yocto-2.3.4.rc1 is now available at: https://autobuilder.yocto.io/pub/releases/yocto-2.3.4.rc1 Please begin QA on this build as soon as possible. Build hash information: meta-intel : 9b37952d6af36358b6397cedf3dd53ec8962b6bf meta-qt4 : 88989ae3abe98b30089e7518d3adabe990c40a10 meta-mingw : c6db1934fc43fb06b93aff3e5634d89cc2b65b77 meta-qt3 : f33b73a9563f2dfdfd0ee37b61d65d90197a456f meta-gplv2 : 627147994943dd562cc294b7ccfd44325744956d poky : ebb42af2829edfca1a23c7a51a431c656ffc2090 This is an automated message from The Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto SDK & Toolchain Deploy Issue
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] [meta-cgl][PATCH] Add LAYERSERIES_COMPAT
On Mon, 2018-05-21 at 12:29 -0700, Jeremy Puhlman wrote:
> From: "Jeremy A. Puhlman"
>
> ---
> meta-cgl-common/conf/layer.conf | 2 +-
> meta-cgl-fsl-ppc/conf/layer.conf | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta-cgl-common/conf/layer.conf b/meta-cgl-
> common/conf/layer.conf
> index bdf5f3f..9384ec7 100644
> --- a/meta-cgl-common/conf/layer.conf
> +++ b/meta-cgl-common/conf/layer.conf
> @@ -10,7 +10,7 @@ BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
> BBFILE_COLLECTIONS += "cgl-common"
> BBFILE_PATTERN_cgl-common = "^${LAYERDIR}/"
> BBFILE_PRIORITY_cgl-common = "7"
> -
> +LAYERSERIES_COMPAT_cgl-common = "sumo"
> LAYERDEPENDS_cgl-common = "core openembedded-layer networking-layer
> perl-layer filesystems-layer security selinux"
>
> require conf/distro/include/cgl_common_security_flags.inc
> diff --git a/meta-cgl-fsl-ppc/conf/layer.conf b/meta-cgl-fsl-
> ppc/conf/layer.conf
> index 353824d..525080c 100644
> --- a/meta-cgl-fsl-ppc/conf/layer.conf
> +++ b/meta-cgl-fsl-ppc/conf/layer.conf
> @@ -10,3 +10,4 @@ BBFILE_PATTERN_cgl-fsl-ppc = "^${LAYERDIR}/"
> BBFILE_PRIORITY_cgl-fsl-ppc = "7"
>
> LAYERDEPENDS_cgl-fsl-ppc = "cgl-common"
> +LAYERSERIES_COMPAT_cgl-fsl-ppc = "sumo"
> --
> 2.6.2
>
hi Jeremy,
Which branch are you sending this for?
Best regards,
--Adrian
This message, including attachments, is CONFIDENTIAL. It may also be privileged
or otherwise protected by law. If you received this email by mistake please let
us know by reply and then delete it from your system; you should not copy it or
disclose its contents to anyone. All messages sent to and from Enea may be
monitored to ensure compliance with internal policies and to protect our
business. Emails are not secure and cannot be guaranteed to be error free as
they can be intercepted, a mended, lost or destroyed, or contain viruses. The
sender therefore does not accept liability for any errors or omissions in the
contents of this message, which arise as a result of email transmission. Anyone
who communicates with us by email accepts these risks.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Problems adding OpenMP to the cross-toolchain installer
Hello Yocto Project, I’m having problems adding OpenMP headers/libraries to the SDK that is installed by the Yocto-generated cross-toolchain installer. Here are the steps that I currently take to add both the dynamic and static OpenMP libraries: 1. I downloaded the poky distribution of Yocto (pyro branch). 2. In order to generate a toolchain installer for the zcu102-zynqmp machine, I also added the “meta-xilinx” layer, using the pyro branch for this as well. 3. At the end of the conf/local.conf file, I added the following: MACHINE = "zcu102-zynqmp" IMAGE_INSTALL_append = " libgomp libgomp-dev libgomp-staticdev glibc-staticdev" SDKIMAGE_FEATURES += " dev-pkgs dbg-pkgs staticdev-pkgs" 1. I generated the toolchain installer with the command: “bitbake meta-toolchain” 2. I ran the toolchain installer (tmp/deploy/sdk/poky-glibc-x86_64-meta-toolchain-aarch64-toolchain-2.3.4.sh) . During the build, there are OMP library/header files created in the build directory (under tmp/work/aarch64-poky-linux/). However, after the toolchain installer is generated and run, the installed SDK directory only includes the following OpenMP library: sysroots/aarch64-poky-linux/usr/lib/.debug/libgomp.so.1.0.0 The problem is that there are no OpenMP header files nor static OpenMP library files in the SDK directory, so OpenMP code can’t be compiled dynamically or statically. I want the toolchain installer to install both the dynamic and static OpenMP libraries and corresponding header files in the appropriate paths under the SDK directory. Any help with this would be appreciated. Please let me know if you’d like further clarification. Thanks, Kaushik -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto SDK & Toolchain Deploy Issue
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] busybox / sysklogd post install conflict
Is it because that these two commands are packaged into busybox instead of busybox-syslog? If some layer introduces such change, then a bbappend file in that layer needs to be added to also modify sysklogd recipe accordingly. Anyway, thanks for raising this problem up. When checking the sysklogd recipe, I found a typo from my previous patch. I've sent out patch to fix it. git://git.pokylinux.org/poky-contrib ChenQi/sysklogd-typo http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/sysklogd-typo Best Regards, Chen Qi On 05/22/2018 11:28 PM, Brian Walsh wrote: I have run into an issue building against sumo branch (using opkg if that matters). This patch removed the update-alternatives for sysklogd. https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=c83eb10f70b714ce3a8c165fad547d800f3ed27d However, busybox is still configured with syslog support. The script that generates all of the symlinks for busybox runs during the main busybox package post install. This causes the post install to exit with an error since it can't create the links for klogd and syslogd if sysklogd is installed without update alternatives. From busybox.postinst: update-alternatives --install /sbin/klogd klogd /bin/busybox.nosuid 50 update-alternatives --install /sbin/syslogd syslogd /bin/busybox.nosuid 50 I think that patch needs to be reverted. The rconflicts for busybox-syslog and sysklogd takes care of the conflicting config file name that is shared between the two packages but we still need the update-alternatives. Unless the function that generates the busybox symlinks gets smart enough to generate the symlinks only in the busybox-syslog package. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
