Date   

Re: wget - The certificate has not yet been activated (does also happen in qemuarm "virt" machine)

Matthias Klein
 

Hello Khem,

this means you are choosing openSSL to provide TLS protocol implementation instead of gnuTLS
Please excuse that my question was so unspecific.
Does it make a functional difference from which library the TLS support comes from?

Best regards,
Matthias


Re: [Openembedded-architecture] Inclusive Language Proposal for YP/OE folllow-up

Tim Orling
 



On Thu, Feb 3, 2022 at 6:31 PM Jon Mason <jdmason@...> wrote:
This is a follow up to the Inclusive Language email I sent out on
January 24 (see
https://lore.kernel.org/yocto/CAPoiz9wL16OTzxNHdw_5-L72GOHkhhM0--WZF7An071cx6sr_A@.../).
I'm adding a couple of additional mailing lists to this email that
were not on the original distribution, in case there are developers
for those areas which didn't see the original email.

I really appreciate the positive feedback received on this.  I've
updated the wiki with the suggested changes by Ross (acked by Randy)
and Mikko, and extrapolated that to be the following list:

CVE_CHECK_PN_WHITELIST ->
CVE_CHECK_SKIPRECIPE ->
CVE_CHECK_SKIP_RECIPE

CVE_CHECK_WHITELIST ->
CVE_CHECK_IGNORECVE ->
CVE_CHECK_IGNORE

INHERIT_BLACKLIST ->
INHERIT_RECIPESKIP ->
INHERIT_RECIPE_SKIP

SDK_LOCAL_CONF_BLACKLIST ->
ESDK_LOCALCONF_REMOVE ->
ESDK_LOCAL_CONF_REMOVE

If anyone wants to nack the changes above, please let me know (or
modify https://wiki.yoctoproject.org/wiki/Inclusive_language).
Similarly, I've added all of the proposed names to the "approved name"
column.

On the same wiki, I've changed the tables to now have a volunteer
developer column (from the "Assigned Developer" name) to make it more
clear that we need help in doing these tasks.  If there is anything
you are interested in, please feel free to put your name down there
and have at it.

This looks to be in good shape. Thank you to the reviewers for some excellent variable names.


Thanks,
Jon




Inclusive Language Proposal for YP/OE folllow-up

Jon Mason
 

This is a follow up to the Inclusive Language email I sent out on
January 24 (see
https://lore.kernel.org/yocto/CAPoiz9wL16OTzxNHdw_5-L72GOHkhhM0--WZF7An071cx6sr_A@mail.gmail.com/).
I'm adding a couple of additional mailing lists to this email that
were not on the original distribution, in case there are developers
for those areas which didn't see the original email.

I really appreciate the positive feedback received on this. I've
updated the wiki with the suggested changes by Ross (acked by Randy)
and Mikko, and extrapolated that to be the following list:

CVE_CHECK_PN_WHITELIST ->
CVE_CHECK_SKIPRECIPE ->
CVE_CHECK_SKIP_RECIPE

CVE_CHECK_WHITELIST ->
CVE_CHECK_IGNORECVE ->
CVE_CHECK_IGNORE

INHERIT_BLACKLIST ->
INHERIT_RECIPESKIP ->
INHERIT_RECIPE_SKIP

SDK_LOCAL_CONF_BLACKLIST ->
ESDK_LOCALCONF_REMOVE ->
ESDK_LOCAL_CONF_REMOVE

If anyone wants to nack the changes above, please let me know (or
modify https://wiki.yoctoproject.org/wiki/Inclusive_language).
Similarly, I've added all of the proposed names to the "approved name"
column.

On the same wiki, I've changed the tables to now have a volunteer
developer column (from the "Assigned Developer" name) to make it more
clear that we need help in doing these tasks. If there is anything
you are interested in, please feel free to put your name down there
and have at it.

Thanks,
Jon


Re: wget - The certificate has not yet been activated (does also happen in qemuarm "virt" machine)

Khem Raj
 

On Thu, Feb 3, 2022 at 9:14 AM Matthias Klein
<matthias.klein@...> wrote:

Hello together,

I can "fix" the bug by switching from gnutls to openssl:

PACKAGECONFIG:remove = "gnutls"
PACKAGECONFIG:append = " openssl"

Can anyone explain this?
What exactly does the change to openssl mean?
this means you are choosing openSSL to provide TLS protocol
implementation instead of gnuTLS


Many greetings,
Matthias



Re: wget - The certificate has not yet been activated (does also happen in qemuarm "virt" machine)

Matthias Klein
 

Hello together,

I can "fix" the bug by switching from gnutls to openssl:

PACKAGECONFIG:remove = "gnutls"
PACKAGECONFIG:append = " openssl"

Can anyone explain this?
What exactly does the change to openssl mean?

Many greetings,
Matthias


Minutes: Yocto Project Weekly Triage Meeting 2/3/2022

Trevor Gamblin
 

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage

Attendees: Alejandro, Alexandre, Andrei, Armin, Bruce, Daiane, Michael, Pavel, Randy, Richard, Saul, Stephen, Steve, Tim, Trevor

ARs:

- Armin/Bruce/Trevor/Saul to move Old Milestone bugs to M3 or later


Notes:

- ~50% of AB workers have been switched to SSDs. Failure rate appears lower, but still TBD

Medium+ 3.5 Unassigned Enhancements/Bugs: 76 (Last week 76)

Medium+ 3.99 Unassigned Enhancements/Bugs: 39 (Last week 39)

AB Bugs: 73 (Last week 76)


Re: IGC build issue with devtoolset-8 (GNU 8.3.1)

Monsees, Steven C (US)
 

 

Is there a CPP conflict due to :

 

./tmp/work/corei7-64-poky-linux/intel-graphics-compiler/1.0.11-r0/git/inc/common/UFO/portable_compiler.h

 

Is this a name space issue ?

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Thursday, February 3, 2022 8:33 AM
To: yocto@...
Subject: Re: [yocto] IGC build issue with devtoolset-8 (GNU 8.3.1)

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

 

Anybody ?

 

It appears to be a CPP issue in the IGC code… but not sure why.

The “__syscall_slong_t” definition appears to be getting resolved out correctly when I replace the array with individual variables of the same type (and the IGC is working)…

 

I’d feel more comfortable patching the IGC, but am still trying to fully understand the root cause…

 

/usr/include/bits>diff stat.h stat.h_HOLD

106c106,108

<     __syscall_slong_t __unused[3];

---

>     __syscall_slong_t __unused1;

>     __syscall_slong_t __unused2;

>     __syscall_slong_t __unused3;

164c166,168

<     __syscall_slong_t __unused[3];

---

>     __syscall_slong_t __unused1;

>     __syscall_slong_t __unused2;

>     __syscall_slong_t __unused3;

08:29 smonsees@yix465383 /usr/include/bits>

 

Note:

 

tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/3d/common/iStdLib/File.h:

 

#elif defined(__GNUC__)

#   include <libgen.h>

#   include <sys/stat.h> <<<---Line #47

#endif

 

sys/stat.h:

 

#include <bits/types.h>         /* For __mode_t and __dev_t.  */

 

#include <bits/stat.h>

 

 

bits/stat.h:    __syscall_slong_t __unused[3];

 

bits/types.h:__STD_TYPE __SYSCALL_SLONG_TYPE __syscall_slong_t;

 

                #if defined __x86_64__ && defined __ILP32__

                                bits/typesizes.h:# define __SYSCALL_SLONG_TYPE            __SQUAD_TYPE

                #else

                                bits/typesizes.h:# define __SYSCALL_SLONG_TYPE            __SLONGWORD_TYPE

 

                #if __WORDSIZE == 32

                                bits/types.h:# define __SQUAD_TYPE                     __quad_t

                #elif __WORDSIZE == 64

                                bits/types.h:# define __SQUAD_TYPE                     long int

 

bits/types.h:

 

#define __SLONGWORD_TYPE   long int

 

 

From: Monsees, Steven C (US)
Sent: Wednesday, February 2, 2022 8:55 AM
To: yocto@...
Subject: IGC build issue with devtoolset-8 (GNU 8.3.1)

 

 

I am building zeus with basic OpenCL support for centos 7.x, and using GNU 8.3.1 compiler and see the following Error when IGC is built, I see the same error when building with GNU 5.3.1…

 

Is this a known issue, is a patch available ?

Any ideas why I might be seeing this ?

 

cpp.o -MF IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/DebugInfo.cpp.o.d -o IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/DebugInfo.cpp.o -c /disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.cpp

| In file included from /usr/include/sys/stat.h:106,

|                  from /disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../3d/common/iStdLib/File.h:47,

|                  from /disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.hpp:42,

|                  from /disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.cpp:26:

| /usr/include/bits/stat.h:106:31: error: expected unqualified-id before ‘[’ token

|      __syscall_slong_t __unused[3];

|                                ^

| /usr/include/bits/stat.h:164:31: error: expected unqualified-id before ‘[’ token

|      __syscall_slong_t __unused[3];

|             

 

I am using bitbake –k, and everything else builds correctly, and no other components references this…

 

If I modify the header like so:

 

/usr/include/bits>diff stat.h stat.h_HOLD

106c106,108

<     __syscall_slong_t __unused[3];

---

>     __syscall_slong_t __unused1;

>     __syscall_slong_t __unused2;

>     __syscall_slong_t __unused3;

164c166,168

<     __syscall_slong_t __unused[3];

---

>     __syscall_slong_t __unused1;

>     __syscall_slong_t __unused2;

>     __syscall_slong_t __unused3;

08:29 smonsees@yix465383 /usr/include/bits>

 

IGC builds clean, and test show it appears to working correctly…

 

I really shouldn’t be modifying the header, and would like to know what the real issue issue is…

 

Thanks,

Steve


Re: IGC build issue with devtoolset-8 (GNU 8.3.1)

Monsees, Steven C (US)
 

 

Anybody ?

 

It appears to be a CPP issue in the IGC code… but not sure why.

The “__syscall_slong_t” definition appears to be getting resolved out correctly when I replace the array with individual variables of the same type (and the IGC is working)…

 

I’d feel more comfortable patching the IGC, but am still trying to fully understand the root cause…

 

/usr/include/bits>diff stat.h stat.h_HOLD

106c106,108

<     __syscall_slong_t __unused[3];

---

>     __syscall_slong_t __unused1;

>     __syscall_slong_t __unused2;

>     __syscall_slong_t __unused3;

164c166,168

<     __syscall_slong_t __unused[3];

---

>     __syscall_slong_t __unused1;

>     __syscall_slong_t __unused2;

>     __syscall_slong_t __unused3;

08:29 smonsees@yix465383 /usr/include/bits>

 

Note:

 

tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/3d/common/iStdLib/File.h:

 

#elif defined(__GNUC__)

#   include <libgen.h>

#   include <sys/stat.h> <<<---Line #47

#endif

 

sys/stat.h:

 

#include <bits/types.h>         /* For __mode_t and __dev_t.  */

 

#include <bits/stat.h>

 

 

bits/stat.h:    __syscall_slong_t __unused[3];

 

bits/types.h:__STD_TYPE __SYSCALL_SLONG_TYPE __syscall_slong_t;

 

                #if defined __x86_64__ && defined __ILP32__

                                bits/typesizes.h:# define __SYSCALL_SLONG_TYPE            __SQUAD_TYPE

                #else

                                bits/typesizes.h:# define __SYSCALL_SLONG_TYPE            __SLONGWORD_TYPE

 

                #if __WORDSIZE == 32

                                bits/types.h:# define __SQUAD_TYPE                     __quad_t

                #elif __WORDSIZE == 64

                                bits/types.h:# define __SQUAD_TYPE                     long int

 

bits/types.h:

 

#define __SLONGWORD_TYPE   long int

 

 

From: Monsees, Steven C (US)
Sent: Wednesday, February 2, 2022 8:55 AM
To: yocto@...
Subject: IGC build issue with devtoolset-8 (GNU 8.3.1)

 

 

I am building zeus with basic OpenCL support for centos 7.x, and using GNU 8.3.1 compiler and see the following Error when IGC is built, I see the same error when building with GNU 5.3.1…

 

Is this a known issue, is a patch available ?

Any ideas why I might be seeing this ?

 

cpp.o -MF IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/DebugInfo.cpp.o.d -o IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/DebugInfo.cpp.o -c /disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.cpp

| In file included from /usr/include/sys/stat.h:106,

|                  from /disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../3d/common/iStdLib/File.h:47,

|                  from /disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.hpp:42,

|                  from /disk0/scratch/yocto_user/yocto/workspace_zeus/builds/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.cpp:26:

| /usr/include/bits/stat.h:106:31: error: expected unqualified-id before ‘[’ token

|      __syscall_slong_t __unused[3];

|                                ^

| /usr/include/bits/stat.h:164:31: error: expected unqualified-id before ‘[’ token

|      __syscall_slong_t __unused[3];

|             

 

I am using bitbake –k, and everything else builds correctly, and no other components references this…

 

If I modify the header like so:

 

/usr/include/bits>diff stat.h stat.h_HOLD

106c106,108

<     __syscall_slong_t __unused[3];

---

>     __syscall_slong_t __unused1;

>     __syscall_slong_t __unused2;

>     __syscall_slong_t __unused3;

164c166,168

<     __syscall_slong_t __unused[3];

---

>     __syscall_slong_t __unused1;

>     __syscall_slong_t __unused2;

>     __syscall_slong_t __unused3;

08:29 smonsees@yix465383 /usr/include/bits>

 

IGC builds clean, and test show it appears to working correctly…

 

I really shouldn’t be modifying the header, and would like to know what the real issue issue is…

 

Thanks,

Steve


Re: [meta-lts-mixins][dunfell/go PATCH 1/4] Initial commit: add license, readme and layer config.

Alexander Kanavin
 

Thanks Michael!
Adrian, the branches are now available:


so I'm ready to take any patches you would like to have there, pls send them via this mailing list. Otherwise I'll get the branches updated to latest component versions.

Alex


On Thu, 3 Feb 2022 at 00:50, Michael Halstead <mhalstead@...> wrote:
Thank you for the ping. These branches are ready for you.

On Tue, Feb 1, 2022 at 6:23 AM Alexander Kanavin <alex.kanavin@...> wrote:
On Thu, 27 Jan 2022 at 21:06, Denys Dmytriyenko <denis@...> wrote:
On Thu, Jan 27, 2022 at 06:07:06PM +0100, Alexander Kanavin wrote:
> A question specifically to Denys, how can I actually get this into the
> mixin repo, and have commit rights to the branch? We've tested this quite
> well in private, and there are further enhancements coming up.

Michael,

Would it be possible to create 2 additional branches in the meta-lts-mixins
repository at https://git.yoctoproject.org/meta-lts-mixins/ called
"dunfell/go" and also "dunfell/docker" and give Alex push rights to them?

Please let us know, thanks a lot!

Ping, please :)

Alex


--
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer


Re: Building of warrior branch fails when building with Ubuntu 20.04 LTS #linux #qemu #yocto

Sourabh Hegde
 

Hello Bernd,

I am facing same issue. Did the patch worked for you? I tried to apply the patch and still have the same issue.

Thanks in advance


Re: Build error:undefined reference to `stime' on Yocto Warrior

Sourabh Hegde
 

Hello,

I applied the patch https://patchwork.openembedded.org/patch/172282/ like below:

Downloaded patch file from above link and deleted below part from patch file:

diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc
index f451017f6d..ad4ff52892 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -27,6 +27,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
            file://0008-linux-user-Fix-webkitgtk-hangs-on-32-bit-x86-target.patch \
            file://0009-Fix-webkitgtk-builds.patch \
            file://0010-configure-Add-pkg-config-handling-for-libgcrypt.patch \
+           file://0011-linux-user-remove-host-stime-syscall.patch \
            file://CVE-2019-15890.patch \
            file://CVE-2019-12068.patch \
            file://CVE-2020-1711.patch \

Because,my /meta/recipes-devtools/qemu/qemu.inc file already has other patches under the anme "0011".

Then I copied the patch file to "poky/meta/recipes-devtools/qemu/qemu/" And appended SRC_URI of "qemu-native.inc" with "file://0015-linux-user-remove-host-stime-syscall.patch \".

After doing bitbake -c cleansstate <image> and bitbake <image> I still get below errors which is related to "x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/syscall.c:7404: undefined reference to `stime'" and some warnings related to utime and stime.

i have attached complete log file for reference.

Can anyone please let me know if patch has been correctly applied and how to resolve this issue?

Thanks in advance.

Your help will be much appreciated.


Re: Private: Re: [yocto] Fetch private gitlab repo using ssh with Yocto recipe #bitbake

Nicolas Jeker
 

Re-adding the list.

On Wed, 2022-02-02 at 11:51 -0800, Sourabh Hegde wrote:
Hi @Nicolas,
Hi Sourabh

Thanks for the detailed answer.

I followed your steps to fix ssh "config" file and now it's working
fine.
Glad to hear it works now.

Regarding my build environment: I am using Docker Desktop for Windows
so i am starting container from Docker Desktop GUI, not from Windows
powershell. So I was confused how to pass "-v
$SSH_AUTH_SOCK:/ssh.socket \".  I hope it's making sense here. Please
do let me know if I am doing anything wrong here so that I don't face
similar issues in future.
I see, I never used Docker Desktop for Windows, so I can't give you
advice about that specifically. If the ssh connection works correctly
with the configuration you created, you shouldn't need to forward the
ssh agent.

Thanks in advance.


wget - The certificate has not yet been activated (does also happen in qemuarm "virt" machine)

Matthias Klein
 

Hello,

another addition to the problem:
The problem does not seem to be directly related to the custom kernel or the one yocto, as I can recreate the problem in a second yocto.

The yocto is for the qemuarm "virt" machine. I have the complete sources for it here: https://github.com/matthiasklein/meta-yocto-coffee-qemuarm

Is it possible that it is somehow related to 32 bit ARM?

# uname -a
Linux qemuarm 5.15.16-yocto-standard #1 SMP PREEMPT Tue Jan 25 14:32:58 UTC 2022 armv7l GNU/Linux

# wget -4 https://speed.hetzner.de/100MB.bin
--2022-02-03 09:18:37-- https://speed.hetzner.de/100MB.bin
SSL_INIT
Resolving speed.hetzner.de... 88.198.248.254
Connecting to speed.hetzner.de|88.198.248.254|:443... connected.
The certificate has not yet been activated

# wget --version
GNU Wget 1.21.2 built on linux-gnueabi.

-cares +digest -gpgme +https +ipv6 -iri +large-file -metalink +nls
+ntlm +opie -psl +ssl/gnutls

Wgetrc:
/etc/wgetrc (system)
Locale:
/usr/share/locale
Compile:
arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard
-mcpu=cortex-a15 -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2
-Wformat -Wformat-security -Werror=format-security -DHAVE_CONFIG_H
-DSYSTEM_WGETRC="/etc/wgetrc" -DLOCALEDIR="/usr/share/locale" -I.
-I../../wget-1.21.2/src -I../lib -I../../wget-1.21.2/lib -DNDEBUG
-O2 -pipe -g -feliminate-unused-debug-types
Link:
arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard
-mcpu=cortex-a15 -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2
-Wformat -Wformat-security -Werror=format-security -DNDEBUG -O2
-pipe -g -feliminate-unused-debug-types -Wl,-O1
-Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now -lpcre
-lnettle -lgnutls -lz ftp-opie.o gnutls.o http-ntlm.o
../lib/libgnu.a -lunistring

Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://www.gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Originally written by Hrvoje Niksic <hniksic@...>.
Please send bug reports and questions to <bug-wget@...>.

Best regards,
Matthias


Re: wget - The certificate has not yet been activated

Matthias Klein
 

Hi,

 

  • check if busybox is built with this option

 

Thank you fort he tip, but I am using the real wget (not from busybox):

 

wget --version

GNU Wget 1.21.2 built on linux-gnueabi.

 

-cares +digest -gpgme +https +ipv6 -iri +large-file -metalink +nls

+ntlm +opie -psl +ssl/gnutls

 

 

Best regards,

Matthias Klein


Re: wget - The certificate has not yet been activated

Markus Volk
 

Hi Matthias,

check if busybox is built with this option

CONFIG_FEATURE_WGET_OPENSSL=y



On Thu, Feb 3 2022 at 06:37:01 AM +0000, Matthias Klein <matthias.klein@...> wrote:
Hello, I have with the current master branch in a IMX6 Yocto the problem that with wget no HTTPS downloads work: # wget -4 https://speed.hetzner.de/100MB.bin --2022-02-03 06:23:25-- https://speed.hetzner.de/100MB.bin SSL_INIT Resolving speed.hetzner.de... 88.198.248.254 Connecting to speed.hetzner.de|88.198.248.254|:443... connected. The certificate has not yet been activated I do not understand why the validation of the certificate does not work. With curl it works. It is also not due to the time of the system. I use my own kernel based on the mainline kernel 5.10.47 with PREEMPT_RT. TARGET_SYS = "arm-poky-linux-gnueabi" TUNE_FEATURES = "arm vfp cortexa9 neon thumb callconvention-hard" TARGET_FPU = "hard" Can it be that something is missing in the kernel configuration? Does anyone have any idea what the problem could be? # wget --version GNU Wget 1.21.2 built on linux-gnueabi. -cares +digest -gpgme +https +ipv6 -iri +large-file -metalink +nls +ntlm +opie -psl +ssl/gnutls Wgetrc: /etc/wgetrc (system) Locale: /usr/share/locale Compile: arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/etc/wgetrc" -DLOCALEDIR="/usr/share/locale" -I. -I../../wget-1.21.2/src -I../lib -I../../wget-1.21.2/lib -DNDEBUG -O2 -pipe -g -feliminate-unused-debug-types Link: arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security -DNDEBUG -O2 -pipe -g -feliminate-unused-debug-types -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now -lpcre -lnettle -lgnutls -lz ftp-opie.o gnutls.o http-ntlm.o ../lib/libgnu.a -lunistring Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://www.gnu.org/licenses/gpl.html. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Originally written by Hrvoje Niksic mailto:hniksic@.... Please send bug reports and questions to mailto:bug-wget@.... A test with gnutls-cli seems to work though: root@smartrail-8037:~# gnutls-cli -d 1 imap.gmail.com -p 993 Processed 127 CA certificate(s). Resolving 'imap.gmail.com:993'... Connecting to '2a00:1450:4013:c02::6d:993'... - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: - subject `CN=imap.gmail.com', issuer `CN=GTS CA 1C3,O=Google Trust Services LLC,C=US', serial 0x65fa03b5a71a05070a000000012e04f6, EC/ECDSA key 256 bits, signed using RSA-SHA256, activated `2022-01-10 03:07:10 UTC', expires `2022-04-04 03:07:09 UTC', pin-sha256="ZrSVXSwpcGu6oCbquwHwx6H2FM7DjzANRxMjQUC/Ng8=" Public Key ID: sha1:ae10ac489504779956e7acfc17631471be3e20d6 sha256:66b4955d2c29706bbaa026eabb01f0c7a1f614cec38f300d4713234140bf360f Public Key PIN: pin-sha256:ZrSVXSwpcGu6oCbquwHwx6H2FM7DjzANRxMjQUC/Ng8= - Certificate[1] info: - subject `CN=GTS CA 1C3,O=Google Trust Services LLC,C=US', issuer `CN=GTS Root R1,O=Google Trust Services LLC,C=US', serial 0x0203bc53596b34c718f5015066, RSA key 2048 bits, signed using RSA-SHA256, activated `2020-08-13 00:00:42 UTC', expires `2027-09-30 00:00:42 UTC', pin-sha256="zCTnfLwLKbS9S2sbp+uFz4KZOocFvXxkV06Ce9O5M2w=" - Certificate[2] info: - subject `CN=GTS Root R1,O=Google Trust Services LLC,C=US', issuer `CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE', serial 0x77bd0d6cdb36f91aea210fc4f058d30d, RSA key 4096 bits, signed using RSA-SHA256, activated `2020-06-19 00:00:42 UTC', expires `2028-01-28 00:00:42 UTC', pin-sha256="hxqRlPTu1bMS/0DITB1SSu0vd4u/8l8TjPgfaAp63Gc=" - Status: The certificate is trusted. - Description: (TLS1.3-X.509)-(ECDHE-X25519)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM) - Session ID: FB:E7:27:9D:B0:8F:4C:2D:0C:5C:E9:17:0F:5C:9B:28:EE:3F:C0:38:0C:43:15:8D:9B:73:A7:AA:BD:AA:F9:87 - Options: - Handshake was completed - Simple Client Mode: * OK Gimap ready for requests from 2a02:908:4c16:7960:20c:c6ff:fe81:e7fa k10mb249481499edf Best regargds, Matthias


wget - The certificate has not yet been activated

Matthias Klein
 

Hello,

I have with the current master branch in a IMX6 Yocto the problem that with wget no HTTPS downloads work:

# wget -4 https://speed.hetzner.de/100MB.bin
--2022-02-03 06:23:25-- https://speed.hetzner.de/100MB.bin
SSL_INIT
Resolving speed.hetzner.de... 88.198.248.254
Connecting to speed.hetzner.de|88.198.248.254|:443... connected.
The certificate has not yet been activated

I do not understand why the validation of the certificate does not work.
With curl it works. It is also not due to the time of the system.
I use my own kernel based on the mainline kernel 5.10.47 with PREEMPT_RT.

TARGET_SYS = "arm-poky-linux-gnueabi"
TUNE_FEATURES = "arm vfp cortexa9 neon thumb callconvention-hard"
TARGET_FPU = "hard"

Can it be that something is missing in the kernel configuration?
Does anyone have any idea what the problem could be?

# wget --version
GNU Wget 1.21.2 built on linux-gnueabi.

-cares +digest -gpgme +https +ipv6 -iri +large-file -metalink +nls
+ntlm +opie -psl +ssl/gnutls

Wgetrc:
/etc/wgetrc (system)
Locale:
/usr/share/locale
Compile:
arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard
-mcpu=cortex-a9 -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2
-Wformat -Wformat-security -Werror=format-security -DHAVE_CONFIG_H
-DSYSTEM_WGETRC="/etc/wgetrc" -DLOCALEDIR="/usr/share/locale" -I.
-I../../wget-1.21.2/src -I../lib -I../../wget-1.21.2/lib -DNDEBUG
-O2 -pipe -g -feliminate-unused-debug-types
Link:
arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard
-mcpu=cortex-a9 -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2
-Wformat -Wformat-security -Werror=format-security -DNDEBUG -O2
-pipe -g -feliminate-unused-debug-types -Wl,-O1
-Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now -lpcre
-lnettle -lgnutls -lz ftp-opie.o gnutls.o http-ntlm.o
../lib/libgnu.a -lunistring

Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://www.gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Originally written by Hrvoje Niksic mailto:hniksic@....
Please send bug reports and questions to mailto:bug-wget@....

A test with gnutls-cli seems to work though:

root@smartrail-8037:~# gnutls-cli -d 1 imap.gmail.com -p 993
Processed 127 CA certificate(s).
Resolving 'imap.gmail.com:993'...
Connecting to '2a00:1450:4013:c02::6d:993'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
- subject `CN=imap.gmail.com', issuer `CN=GTS CA 1C3,O=Google Trust Services LLC,C=US', serial 0x65fa03b5a71a05070a000000012e04f6, EC/ECDSA key 256 bits, signed using RSA-SHA256, activated `2022-01-10 03:07:10 UTC', expires `2022-04-04 03:07:09 UTC', pin-sha256="ZrSVXSwpcGu6oCbquwHwx6H2FM7DjzANRxMjQUC/Ng8="
Public Key ID:
sha1:ae10ac489504779956e7acfc17631471be3e20d6
sha256:66b4955d2c29706bbaa026eabb01f0c7a1f614cec38f300d4713234140bf360f
Public Key PIN:
pin-sha256:ZrSVXSwpcGu6oCbquwHwx6H2FM7DjzANRxMjQUC/Ng8=

- Certificate[1] info:
- subject `CN=GTS CA 1C3,O=Google Trust Services LLC,C=US', issuer `CN=GTS Root R1,O=Google Trust Services LLC,C=US', serial 0x0203bc53596b34c718f5015066, RSA key 2048 bits, signed using RSA-SHA256, activated `2020-08-13 00:00:42 UTC', expires `2027-09-30 00:00:42 UTC', pin-sha256="zCTnfLwLKbS9S2sbp+uFz4KZOocFvXxkV06Ce9O5M2w="
- Certificate[2] info:
- subject `CN=GTS Root R1,O=Google Trust Services LLC,C=US', issuer `CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE', serial 0x77bd0d6cdb36f91aea210fc4f058d30d, RSA key 4096 bits, signed using RSA-SHA256, activated `2020-06-19 00:00:42 UTC', expires `2028-01-28 00:00:42 UTC', pin-sha256="hxqRlPTu1bMS/0DITB1SSu0vd4u/8l8TjPgfaAp63Gc="
- Status: The certificate is trusted.
- Description: (TLS1.3-X.509)-(ECDHE-X25519)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
- Session ID: FB:E7:27:9D:B0:8F:4C:2D:0C:5C:E9:17:0F:5C:9B:28:EE:3F:C0:38:0C:43:15:8D:9B:73:A7:AA:BD:AA:F9:87
- Options:
- Handshake was completed

- Simple Client Mode:

* OK Gimap ready for requests from 2a02:908:4c16:7960:20c:c6ff:fe81:e7fa k10mb249481499edf

Best regargds,
Matthias


Re: [meta-lts-mixins][dunfell/go PATCH 1/4] Initial commit: add license, readme and layer config.

Michael Halstead
 

Thank you for the ping. These branches are ready for you.


On Tue, Feb 1, 2022 at 6:23 AM Alexander Kanavin <alex.kanavin@...> wrote:
On Thu, 27 Jan 2022 at 21:06, Denys Dmytriyenko <denis@...> wrote:
On Thu, Jan 27, 2022 at 06:07:06PM +0100, Alexander Kanavin wrote:
> A question specifically to Denys, how can I actually get this into the
> mixin repo, and have commit rights to the branch? We've tested this quite
> well in private, and there are further enhancements coming up.

Michael,

Would it be possible to create 2 additional branches in the meta-lts-mixins
repository at https://git.yoctoproject.org/meta-lts-mixins/ called
"dunfell/go" and also "dunfell/docker" and give Alex push rights to them?

Please let us know, thanks a lot!

Ping, please :)

Alex


--
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer


Issues setting SELinux file contexts during build #selinux

Ansh
 

Hi all,

I am currently working on enabling SELinux on an x86 system (Yocto version 2.4). I was able to successfully enable SELinux on the target but need to set SELinux file contexts during the build. I have inherited the selinux-image.bbclass in my image recipe and can confirm that it's executed during the build. But, when I boot up the image on target all the files have the wrong (or default) file contexts. For e.g. all files in /etc have system_u:object_r:root_t:s0 labels. When I run restorecon, the files get the correct labels. I have managed to narrow it down to the following two issues:

1. setfiles fails during the build but doesn't return any error or error msg causing the build to pass

I looked into the pseudo database table xattr to check if the xattrs are set during the build and found the table empty. So I modified the selinux-image.bbclass and added a setfattr to set xattr for a single file in /etc before it runs setfiles. After the build, I found one entry for the same file for which I was using the setfattr command in the xattr table of pseudo db and was also able to get the xattr using getfattr in the modified selinux-image.bbclass. So that means setfattr was working as expected but not setfiles. Next, I enabled some debug logs for pseudo and found the following that points to setfiles failing after it tries to read security.restorecon_last. Any pointer as to why it is trying to read security.restorecon_last xattr (even though we are not using -d option for setfiles) and fails if it doesn't find it?

27286: wrapper called: getxattr
27286: getxattr - signals blocked, obtaining lock
27286: <nil> + build/tmp/work/x86_ctm-poky-linux-musl/custom-image/1.0-r0/rootfs => <build/tmp/work/x86_ctm-poky-linux-musl/custom-image/1.0-r0/rootfs>
27286: base_path: <nil></>build/tmp/work/x86_ctm-poky-linux-musl/custom-image/1.0-r0/rootfs
27286: root_path [getxattr, 7008]: 'build/tmp/work/x86_ctm-poky-linux-musl/custom-image/1.0-r0/rootfs' from 'build/tmp/work/x86_ctm-poky-linux-musl/custom-image/1.0-r0/rootfs'
27286: getxattr(build/tmp/work/x86_ctm-poky-linux-musl/custom-image/1.0-r0/rootfs [fd -1], security.restorecon_last)
27286: getxattr, name 'security.restorecon_last' 27286: get-xattr security.restorecon_last -> build/tmp/work/x86_ctm-poky-linux-musl/custom-image/1.0-r0/rootfs (+buf) (040755): processing request [ino 146615528]
27286: sending request [ino 146615528] 27286: sending a message: ino 146615528 27286: msg type 3 (get-xattr), external path build/tmp/work/x86_ctm-poky-linux-musl/custom-image/1.0-r0/rootfs, mode 040755
27286: wrote 184 bytes 27286: sent! 27286: got header, type 4, pathlen 0 27286: got response type 4 27286: (27286) fail

 2. xattrs set during the build are not present on the target

As mentioned above, I modified to selinux-image.bbclass to set xattr for a single file in /etc. This works during the build since I can see the corresponding entry in pseudo db and also can get the set xattr using getfattr in the same selinux-image.bbclass. But when I boot up the image on target the xattr is replaced by (I am guessing) the default SELinux label of system_u:object_r:root_t:s0. I am using initramfs for packaging the root filesystem and I found that cpio ignores xattrs and also initramfs doesn't support xattrs. Does that mean I can't set the file contexts during the build because I am using initramfs and cpio?

Thanks,
Ansh


Re: Build error:undefined reference to `stime' on Yocto Warrior

Sourabh Hegde
 

Hello @Khem,

Thanks for the quick response.

Can you please let me know where and how to include this patch in poky/meta?

Thanks in advance

On Wed, Feb 2, 2022, 21:19 Khem Raj <raj.khem@...> wrote:
you need something like this

https://patchwork.openembedded.org/patch/172282/

On Wed, Feb 2, 2022 at 11:43 AM Sourabh Hegde <hrsourabh011@...> wrote:
>
> Hello All,
>
> When I execute the bitbake for my custom image recipe I hit the below issue related to "qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/syscall.c:7404: undefined reference to `stime'".
>
> DEBUG: Executing shell function do_compile
> NOTE: make -j 8 LD=ld  AR=ar OBJCOPY=objcopy LDFLAGS=-L/root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/recipe-sysroot-native/usr/lib                         -L/root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/recipe-sysroot-native/lib                         -Wl,--enable-new-dtags                         -Wl,-rpath-link,/root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/recipe-sysroot-native/usr/lib                         -Wl,-rpath-link,/root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/recipe-sysroot-native/lib                         -Wl,-rpath,/root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/recipe-sysroot-native/usr/lib                         -Wl,-rpath,/root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/recipe-sysroot-native/lib                         -Wl,-O1 -fuse-ld=bfd
>   LINK    i386-linux-user/qemu-i386
>   LINK    mipsel-linux-user/qemu-mipsel
>   LINK    arm-linux-user/qemu-arm
>   LINK    mips-linux-user/qemu-mips
>   LINK    ppc-linux-user/qemu-ppc
>   GEN     x86_64-linux-user/config-target.h
>   LINK    sh4-linux-user/qemu-sh4
>   CC      x86_64-linux-user/exec.o
>   CC      x86_64-linux-user/tcg/tcg.o
>   CC      x86_64-linux-user/tcg/tcg-op.o
> /root/build-rauc/tmp-glibc/hosttools/ld.bfd: linux-user/syscall.o: in function `do_syscall1':
> /root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/syscall.c:7404: undefined reference to `stime'
> collect2: error: ld returned 1 exit status
> make[1]: *** [Makefile:199: qemu-arm] Error 1
> make: *** [Makefile:483: subdir-arm-linux-user] Error 2
> make: *** Waiting for unfinished jobs....
>   CC      x86_64-linux-user/tcg/tcg-op-vec.o
> /root/build-rauc/tmp-glibc/hosttools/ld.bfd: linux-user/syscall.o: in function `do_syscall1':
> /root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/syscall.c:7404: undefined reference to `stime'
> collect2: error: ld returned 1 exit status
> make[1]: *** [Makefile:199: qemu-i386] Error 1
> make: *** [Makefile:483: subdir-i386-linux-user] Error 2
>   CC      x86_64-linux-user/tcg/tcg-op-gvec.o
> /root/build-rauc/tmp-glibc/hosttools/ld.bfd: linux-user/syscall.o: in function `do_syscall1':
> /root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/syscall.c:7404: undefined reference to `stime'
> collect2: error: ld returned 1 exit status
> make[1]: *** [Makefile:199: qemu-sh4] Error 1
> make: *** [Makefile:483: subdir-sh4-linux-user] Error 2
>   CC      x86_64-linux-user/tcg/tcg-common.o
> /root/build-rauc/tmp-glibc/hosttools/ld.bfd: linux-user/syscall.o: in function `do_syscall1':
> /root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/syscall.c:7404: undefined reference to `stime'
> collect2: error: ld returned 1 exit status
> make[1]: *** [Makefile:199: qemu-ppc] Error 1
> make: *** [Makefile:483: subdir-ppc-linux-user] Error 2
>   CC      x86_64-linux-user/tcg/optimize.o
> /root/build-rauc/tmp-glibc/hosttools/ld.bfd: linux-user/syscall.o: in function `do_syscall1':
> /root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/syscall.c:7404: undefined reference to `stime'
> collect2: error: ld returned 1 exit status
> make[1]: *** [Makefile:199: qemu-mipsel] Error 1
> make: *** [Makefile:483: subdir-mipsel-linux-user] Error 2
>   CC      x86_64-linux-user/fpu/softfloat.o
> /root/build-rauc/tmp-glibc/hosttools/ld.bfd: linux-user/syscall.o: in function `do_syscall1':
> /root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/syscall.c:7404: undefined reference to `stime'
> collect2: error: ld returned 1 exit status
> make[1]: *** [Makefile:199: qemu-mips] Error 1
> make: *** [Makefile:483: subdir-mips-linux-user] Error 2
>   CC      x86_64-linux-user/disas.o
>   GEN     x86_64-linux-user/gdbstub-xml.c
>   CC      x86_64-linux-user/gdbstub.o
>   CC      x86_64-linux-user/thunk.o
>   CC      x86_64-linux-user/accel/stubs/hax-stub.o
>   CC      x86_64-linux-user/accel/stubs/hvf-stub.o
>   CC      x86_64-linux-user/accel/stubs/whpx-stub.o
>   CC      x86_64-linux-user/accel/stubs/kvm-stub.o
>   CC      x86_64-linux-user/accel/tcg/tcg-runtime.o
>   CC      x86_64-linux-user/accel/tcg/tcg-runtime-gvec.o
>   CC      x86_64-linux-user/accel/tcg/cpu-exec.o
>   CC      x86_64-linux-user/accel/tcg/cpu-exec-common.o
>   CC      x86_64-linux-user/accel/tcg/translate-all.o
>   CC      x86_64-linux-user/accel/tcg/translator.o
>   CC      x86_64-linux-user/accel/tcg/user-exec.o
>   CC      x86_64-linux-user/accel/tcg/user-exec-stub.o
>   CC      x86_64-linux-user/linux-user/main.o
>   CC      x86_64-linux-user/linux-user/syscall.o
>   CC      x86_64-linux-user/linux-user/strace.o
>   CC      x86_64-linux-user/linux-user/mmap.o
>   CC      x86_64-linux-user/linux-user/signal.o
>   CC      x86_64-linux-user/linux-user/elfload.o
> In file included from /usr/include/string.h:495,
>                  from /root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/include/qemu/osdep.h:84,
>                  from /root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/elfload.c:2:
> In function ‘strncpy’,
>     inlined from ‘fill_psinfo’ at /root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/elfload.c:3158:12,
>     inlined from ‘fill_note_info’ at /root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/elfload.c:3340:5,
>     inlined from ‘elf_core_dump’ at /root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/elfload.c:3489:9:
> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’ specified bound 16 equals destination size [-Wstringop-truncation]
>   106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
>       |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   CC      x86_64-linux-user/linux-user/linuxload.o
>   CC      x86_64-linux-user/linux-user/uaccess.o
>   CC      x86_64-linux-user/linux-user/uname.o
>   CCAS    x86_64-linux-user/linux-user/safe-syscall.o
>   CC      x86_64-linux-user/linux-user/x86_64/signal.o
>   CC      x86_64-linux-user/linux-user/x86_64/cpu_loop.o
>   CC      x86_64-linux-user/linux-user/exit.o
>   CC      x86_64-linux-user/linux-user/fd-trans.o
>   CC      x86_64-linux-user/target/i386/helper.o
>   CC      x86_64-linux-user/target/i386/cpu.o
>   CC      x86_64-linux-user/target/i386/gdbstub.o
>   CC      x86_64-linux-user/target/i386/xsave_helper.o
>   CC      x86_64-linux-user/target/i386/translate.o
>   CC      x86_64-linux-user/target/i386/bpt_helper.o
>   CC      x86_64-linux-user/target/i386/cc_helper.o
>   CC      x86_64-linux-user/target/i386/excp_helper.o
>   CC      x86_64-linux-user/target/i386/fpu_helper.o
>   CC      x86_64-linux-user/target/i386/int_helper.o
>   CC      x86_64-linux-user/target/i386/mem_helper.o
>   CC      x86_64-linux-user/target/i386/misc_helper.o
>   CC      x86_64-linux-user/target/i386/mpx_helper.o
>   CC      x86_64-linux-user/target/i386/seg_helper.o
>   CC      x86_64-linux-user/target/i386/smm_helper.o
>   CC      x86_64-linux-user/target/i386/svm_helper.o
>   CC      x86_64-linux-user/target/i386/sev-stub.o
>   GEN     trace/generated-helpers.c
>   CC      x86_64-linux-user/trace/control-target.o
>   CC      x86_64-linux-user/gdbstub-xml.o
>   CC      x86_64-linux-user/trace/generated-helpers.o
>   LINK    x86_64-linux-user/qemu-x86_64
> ERROR: oe_runmake failed
> WARNING: exit code 1 from a shell command.
> ERROR: Function failed: do_compile (log file is located at /root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/temp/log.do_compile.5584)
>
>
> I am using "Warrior" version due to limitation from other meta-layers. I have read that above issue is fixed in newer versions of Yocto. But how can i fix this in Warrior? Is there any workaround?
>
> Can someone please help me resolve it?
>
> Your help will be much appreciated.
>
> Thanks in advance.
>
>


Re: Build error:undefined reference to `stime' on Yocto Warrior

Khem Raj
 

On Wed, Feb 2, 2022 at 11:43 AM Sourabh Hegde <hrsourabh011@...> wrote:

Hello All,

When I execute the bitbake for my custom image recipe I hit the below issue related to "qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/syscall.c:7404: undefined reference to `stime'".

DEBUG: Executing shell function do_compile
NOTE: make -j 8 LD=ld AR=ar OBJCOPY=objcopy LDFLAGS=-L/root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/recipe-sysroot-native/usr/lib -L/root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/recipe-sysroot-native/lib -Wl,--enable-new-dtags -Wl,-rpath-link,/root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/recipe-sysroot-native/usr/lib -Wl,-rpath-link,/root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/recipe-sysroot-native/lib -Wl,-rpath,/root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/recipe-sysroot-native/usr/lib -Wl,-rpath,/root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/recipe-sysroot-native/lib -Wl,-O1 -fuse-ld=bfd
LINK i386-linux-user/qemu-i386
LINK mipsel-linux-user/qemu-mipsel
LINK arm-linux-user/qemu-arm
LINK mips-linux-user/qemu-mips
LINK ppc-linux-user/qemu-ppc
GEN x86_64-linux-user/config-target.h
LINK sh4-linux-user/qemu-sh4
CC x86_64-linux-user/exec.o
CC x86_64-linux-user/tcg/tcg.o
CC x86_64-linux-user/tcg/tcg-op.o
/root/build-rauc/tmp-glibc/hosttools/ld.bfd: linux-user/syscall.o: in function `do_syscall1':
/root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/syscall.c:7404: undefined reference to `stime'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:199: qemu-arm] Error 1
make: *** [Makefile:483: subdir-arm-linux-user] Error 2
make: *** Waiting for unfinished jobs....
CC x86_64-linux-user/tcg/tcg-op-vec.o
/root/build-rauc/tmp-glibc/hosttools/ld.bfd: linux-user/syscall.o: in function `do_syscall1':
/root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/syscall.c:7404: undefined reference to `stime'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:199: qemu-i386] Error 1
make: *** [Makefile:483: subdir-i386-linux-user] Error 2
CC x86_64-linux-user/tcg/tcg-op-gvec.o
/root/build-rauc/tmp-glibc/hosttools/ld.bfd: linux-user/syscall.o: in function `do_syscall1':
/root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/syscall.c:7404: undefined reference to `stime'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:199: qemu-sh4] Error 1
make: *** [Makefile:483: subdir-sh4-linux-user] Error 2
CC x86_64-linux-user/tcg/tcg-common.o
/root/build-rauc/tmp-glibc/hosttools/ld.bfd: linux-user/syscall.o: in function `do_syscall1':
/root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/syscall.c:7404: undefined reference to `stime'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:199: qemu-ppc] Error 1
make: *** [Makefile:483: subdir-ppc-linux-user] Error 2
CC x86_64-linux-user/tcg/optimize.o
/root/build-rauc/tmp-glibc/hosttools/ld.bfd: linux-user/syscall.o: in function `do_syscall1':
/root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/syscall.c:7404: undefined reference to `stime'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:199: qemu-mipsel] Error 1
make: *** [Makefile:483: subdir-mipsel-linux-user] Error 2
CC x86_64-linux-user/fpu/softfloat.o
/root/build-rauc/tmp-glibc/hosttools/ld.bfd: linux-user/syscall.o: in function `do_syscall1':
/root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/syscall.c:7404: undefined reference to `stime'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:199: qemu-mips] Error 1
make: *** [Makefile:483: subdir-mips-linux-user] Error 2
CC x86_64-linux-user/disas.o
GEN x86_64-linux-user/gdbstub-xml.c
CC x86_64-linux-user/gdbstub.o
CC x86_64-linux-user/thunk.o
CC x86_64-linux-user/accel/stubs/hax-stub.o
CC x86_64-linux-user/accel/stubs/hvf-stub.o
CC x86_64-linux-user/accel/stubs/whpx-stub.o
CC x86_64-linux-user/accel/stubs/kvm-stub.o
CC x86_64-linux-user/accel/tcg/tcg-runtime.o
CC x86_64-linux-user/accel/tcg/tcg-runtime-gvec.o
CC x86_64-linux-user/accel/tcg/cpu-exec.o
CC x86_64-linux-user/accel/tcg/cpu-exec-common.o
CC x86_64-linux-user/accel/tcg/translate-all.o
CC x86_64-linux-user/accel/tcg/translator.o
CC x86_64-linux-user/accel/tcg/user-exec.o
CC x86_64-linux-user/accel/tcg/user-exec-stub.o
CC x86_64-linux-user/linux-user/main.o
CC x86_64-linux-user/linux-user/syscall.o
CC x86_64-linux-user/linux-user/strace.o
CC x86_64-linux-user/linux-user/mmap.o
CC x86_64-linux-user/linux-user/signal.o
CC x86_64-linux-user/linux-user/elfload.o
In file included from /usr/include/string.h:495,
from /root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/include/qemu/osdep.h:84,
from /root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/elfload.c:2:
In function ‘strncpy’,
inlined from ‘fill_psinfo’ at /root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/elfload.c:3158:12,
inlined from ‘fill_note_info’ at /root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/elfload.c:3340:5,
inlined from ‘elf_core_dump’ at /root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/elfload.c:3489:9:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’ specified bound 16 equals destination size [-Wstringop-truncation]
106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CC x86_64-linux-user/linux-user/linuxload.o
CC x86_64-linux-user/linux-user/uaccess.o
CC x86_64-linux-user/linux-user/uname.o
CCAS x86_64-linux-user/linux-user/safe-syscall.o
CC x86_64-linux-user/linux-user/x86_64/signal.o
CC x86_64-linux-user/linux-user/x86_64/cpu_loop.o
CC x86_64-linux-user/linux-user/exit.o
CC x86_64-linux-user/linux-user/fd-trans.o
CC x86_64-linux-user/target/i386/helper.o
CC x86_64-linux-user/target/i386/cpu.o
CC x86_64-linux-user/target/i386/gdbstub.o
CC x86_64-linux-user/target/i386/xsave_helper.o
CC x86_64-linux-user/target/i386/translate.o
CC x86_64-linux-user/target/i386/bpt_helper.o
CC x86_64-linux-user/target/i386/cc_helper.o
CC x86_64-linux-user/target/i386/excp_helper.o
CC x86_64-linux-user/target/i386/fpu_helper.o
CC x86_64-linux-user/target/i386/int_helper.o
CC x86_64-linux-user/target/i386/mem_helper.o
CC x86_64-linux-user/target/i386/misc_helper.o
CC x86_64-linux-user/target/i386/mpx_helper.o
CC x86_64-linux-user/target/i386/seg_helper.o
CC x86_64-linux-user/target/i386/smm_helper.o
CC x86_64-linux-user/target/i386/svm_helper.o
CC x86_64-linux-user/target/i386/sev-stub.o
GEN trace/generated-helpers.c
CC x86_64-linux-user/trace/control-target.o
CC x86_64-linux-user/gdbstub-xml.o
CC x86_64-linux-user/trace/generated-helpers.o
LINK x86_64-linux-user/qemu-x86_64
ERROR: oe_runmake failed
WARNING: exit code 1 from a shell command.
ERROR: Function failed: do_compile (log file is located at /root/build-rauc/tmp-glibc/work/x86_64-linux/qemu-native/3.1.1.1-r0/temp/log.do_compile.5584)


I am using "Warrior" version due to limitation from other meta-layers. I have read that above issue is fixed in newer versions of Yocto. But how can i fix this in Warrior? Is there any workaround?

Can someone please help me resolve it?

Your help will be much appreciated.

Thanks in advance.

2201 - 2220 of 58220