On Tue, 11 Feb 2020, Ross Burton wrote:
> Ah gotcha. My docbook-fu is somewhat hazy.
>
> Yes, seems sensible.
>
> Ross
>
> On Tue, 11 Feb 2020 at 14:43, Robert P. J. Day wrote:
> >
> > On Tue, 11 Feb 2020, Ross Burton wrote:
> >
> > > My problem with is that you need to keep on reviewing to
>
That layer does have the x86_64 variant as well, no? Is it not working?
https://github.com/RDunkley/meta-dotnet-core/blob/master/recipes-runtime/dotnet-core/dotnet-core_3.1.1.inc
The error you're seeing is almost certainly due to Yocto using
/lib/ld-so... for dynamic loader, and the binary
Ok, I created a symbolic link with "ln -s /lib /lib64" and it seemed to work.
Thanks a lot.
Von: yocto@lists.yoctoproject.org Im Auftrag von
Alexander Kanavin
Gesendet: Mittwoch, 12. Februar 2020 12:00
An: Lohr, Christian [ext]
Cc: yocto@lists.yoctoproject.org
Betreff: Re: [yocto] Creating a
Yocto generally does not support this use case. The binary was compiled in
a different environment and expects things in different places, and
probably being different versions too. I could point out the specific
problem why the executable doesn't even start, but it's really the wrong
way to
Hello,
I'm trying to create a normal QEmu (x86-64) Image, which I can let run in
Virtualbox. As a addition I deployed .NET Core, which I got from this side:
https://dotnet.microsoft.com/download/dotnet-core/thank-you/runtime-aspnetcore-3.1.1-linux-x64-binaries
But I can't execute it:
Hello Alex,
Thanks for replying. Yes, I know that this isn't the way it works on Yocto (and
I told the managers it is a crappy idea to do that more than once). But they
need .NET Core in that company I work for, and Mono doesn't work (that's what
they told me). Compiling .NET Core through the
I used the x86_64 variant from the layer (it only downloads the binaries and
copies them).
And I checked that with ldd, it seemed ok so far:
-
root@qemux86-64:/usr/share/dotnet# ldd dotnet
linux-vdso.so.1 (0x7fffea543000)
But this is exactly what happens: the kernel reads the dynamic
loader/interpreter path from the binary (which is different than the list
of dynamically linked libraries printed by ldd), isn't able to find it and
stops right there.
Try like this:
/lib/ld-linux-x86-64.so.2 /usr/share/dotnet/dotnet
Now that we've switched to using wic for image layout, we can remove the
unused recipes for proprietary vendor tools.
Signed-off-by: Trevor Woerner
---
.../mkbootimg/mkbootimg-native_git.bb | 24
.../rkflashtool/rkflashtool-native_git.bb | 28 ---
2
On Wed, Feb 12, 2020 at 1:13 PM Alexandru N. Onea wrote:
>
> Hello community,
>
> I have noticed that do_kernel_metadata is always executed before do_patch.
> What is the reason for this ordering?
>
> In my setup, I have a patch that changes some options in the in-tree
> defconfig that I want
Hello community,
I have noticed that do_kernel_metadata is always executed before do_patch.
What is the reason for this ordering?
In my setup, I have a patch that changes some options in the in-tree
defconfig that I want to use (set using KBUILD_DEFCONFIG) and, due to the
ordering mentioned
Hi Vijay,
Note that the yocto-builds list is for automated tests and reports.
The usual list is:
yocto@lists.yoctoproject.org
See below for my reply once I address the email list confusion.
Michael,
Can you help here or should I contact someone else?
Since this isn't the first time someone
Hi,
i have a working configuration with images and rauc bundles. My problem is that
kernel and devicetree are located outside the rootfs and so a bundle update
never includes these.
My image.wks looks this:
part BAREBOX --source rawcopy --sourceparams="file=barebox.bin,skip=1024"
--ondisk mmc
On 2/12/20 3:19 AM, Christian Lohr wrote:
Ok, I created a symbolic link with “ln -s /lib /lib64” and it seemed to
work. Thanks a lot.
right, if you built multilib image then it will be using /lib64
automatically.
Hi!
I am having problems with my raspberry pi3 a+ yocto thud build when connecting
a LTE E3372 modem. Sometimes it works but most of the times the startup of the
LTE device interfere with services that are started ending up with blocking the
raspberry pi.
I want to test to delay the startup
Hi Hans,
Am 12.02.20 um 18:54 schrieb Hans-Ulrich Schlieben:
> Hi,
>
> i have a working configuration with images and rauc bundles. My problem
> is that kernel and devicetree are located outside the rootfs and so a
> bundle update never includes these.
a RAUC bundle can contain images for
Had to use the fail2ban-2.3 program to create py3 code
Add it as a patch
Signed-off-by: Armin Kuster
---
...0001-python3-fail2ban-2-3-conversion.patch | 2527 +
.../fail2ban/files/fail2ban_setup.py |1 -
.../fail2ban/python3-fail2ban_0.10.4.0.bb |4 +-
3
On 2/12/20 7:06 PM, Jain, Sangeeta wrote:
>
>
> Hello All,
>
> Intel and WR YP QA is planning for QA execution for YP build yocto-3.0.2.rc2
> starting from WW8.1
> We are planning to execute following tests for this cycle:
>
> OEQA-manual tests for following module:
> 1. OE-Core
> 2. BSP-hw
>
>
Hello All,
Intel and WR YP QA is planning for QA execution for YP build yocto-3.0.2.rc2
starting from WW8.1
We are planning to execute following tests for this cycle:
OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw
Runtime auto test for following platforms:
1. MinnowTurbot
19 matches
Mail list logo