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 sysklog
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
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 Yoc
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
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
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 : 88989ae3abe9
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
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/f2e77865e144ab2e1313aa78d99b969f8f4869
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
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 s
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 50e755
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
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-
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
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
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
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 i
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
18 matches
Mail list logo
