Date   

Yocto gdb build error on Microblaze platform

R Keith Beal
 

Fellow Developers,


I am attempting to add gdb to a Yocto project based on Yocto 2.3 (Pyro).

The build complains about a missing libreadline.a.


| make[2]: Leaving directory '/opt/yocto/yocto-bwc/builds/microblazeel/tmp/work/microblazeel-v9.6-bs-cmp-mh-poky-linux/gdb/7.7.1-r0/build-microblazeel-poky-linux/opcodes'

| make[2]: Entering directory '/opt/yocto/yocto-bwc/builds/microblazeel/tmp/work/microblazeel-v9.6-bs-cmp-mh-poky-linux/gdb/7.7.1-r0/build-microblazeel-poky-linux/gdb'

| make[2]: *** No rule to make target '../readline/libreadline.a', needed by 'gdb'.  Stop.

| make[2]: *** Waiting for unfinished jobs....

 

I tried several solutions from related searches.

https://www.yoctoproject.org/pipermail/yocto/2017-June/036676.html

https://yocto.yoctoproject.narkive.com/gUVw5u2k/failed-to-build-gdb

 

Tried PACKAGECONFIG_remove_pn-gdb = "readline" but it does not help.

Tried adding EXTRA_OECONF_append = " --without-system-readline" to the image recipe but it doesn’t help.

 

From /opt/yocto/yocto-bwc/builds/microblazeel/tmp/work/microblazeel-v9.6-bs-cmp-mh-poky-linux/gdb/7.7.1-r0/gdb-7.7.1/gdb/Makefile.in

# Where is the READLINE library?  Typically in ../readline.

READLINE_DIR = ../readline

READLINE_SRC = $(srcdir)/$(READLINE_DIR)

READLINE = @READLINE@

READLINE_DEPS = @READLINE_DEPS@

READLINE_CFLAGS = @READLINE_CFLAGS@

 

I tried adding PACKAGECONFIG_remove_pn-gdb = "readline" to the local.conf


As a test, I manually built gdb’s local copy of readline and I get lots of compile errors that look like some sort of version skew with the thread library.

| In file included from ../../gdb-7.7.1/gdb/proc-service.c:28:0:

| ../../gdb-7.7.1/gdb/gdb_proc_service.h:162:9: error: unknown type name 'gdb_fpregset_t'

|  typedef gdb_fpregset_t gdb_prfpregset_t;

|          ^~~~~~~~~~~~~~

| ../../gdb-7.7.1/gdb/proc-service.c:151:1: warning: no previous prototype for 'ps_lgetxregsize' [-Wmissing-prototypes]

|  ps_lgetxregsize (gdb_ps_prochandle_t ph, lwpid_t lwpid, int *xregsize)

|  ^~~~~~~~~~~~~~~

| ../../gdb-7.7.1/gdb/proc-service.c:161:1: warning: no previous prototype for 'ps_lgetxregs' [-Wmissing-prototypes]

|  ps_lgetxregs (gdb_ps_prochandle_t ph, lwpid_t lwpid, caddr_t xregset)

|  ^~~~~~~~~~~~

| ../../gdb-7.7.1/gdb/proc-service.c:171:1: warning: no previous prototype for 'ps_lsetxregs' [-Wmissing-prototypes]

|  ps_lsetxregs (gdb_ps_prochandle_t ph, lwpid_t lwpid, caddr_t xregset)

|  ^~~~~~~~~~~~

| ../../gdb-7.7.1/gdb/proc-service.c:180:1: warning: no previous prototype for 'ps_plog' [-Wmissing-prototypes]

|  ps_plog (const char *fmt, ...)

|  ^~~~~~~

| ../../gdb-7.7.1/gdb/proc-service.c:298:1: error: conflicting types for 'ps_lgetfpregs'

|  ps_lgetfpregs (gdb_ps_prochandle_t ph, lwpid_t lwpid,

|  ^~~~~~~~~~~~~

| In file included from ../../gdb-7.7.1/gdb/gdb_proc_service.h:25:0,

|                  from ../../gdb-7.7.1/gdb/proc-service.c:28:

| /opt/yocto/yocto-bwc/builds/microblazeel/tmp/work/microblazeel-v9.6-bs-cmp-mh-poky-linux/gdb/7.7.1-r0/recipe-sysroot/usr/include/proc_service.h:61:17: note: previous declaration of 'ps_lgetfpregs' was here

|  extern ps_err_e ps_lgetfpregs (struct ps_prochandle *,

|                  ^~~~~~~~~~~~~

| ../../gdb-7.7.1/gdb/proc-service.c:318:1: error: conflicting types for 'ps_lsetfpregs'

|  ps_lsetfpregs (gdb_ps_prochandle_t ph, lwpid_t lwpid,

|  ^~~~~~~~~~~~~

| In file included from ../../gdb-7.7.1/gdb/gdb_proc_service.h:25:0,

|                  from ../../gdb-7.7.1/gdb/proc-service.c:28:

| /opt/yocto/yocto-bwc/builds/microblazeel/tmp/work/microblazeel-v9.6-bs-cmp-mh-poky-linux/gdb/7.7.1-r0/recipe-sysroot/usr/include/proc_service.h:63:17: note: previous declaration of 'ps_lsetfpregs' was here

|  extern ps_err_e ps_lsetfpregs (struct ps_prochandle *,

|                  ^~~~~~~~~~~~~

| ERROR: oe_runmake failed

| Makefile:1011: recipe for target 'proc-service.o' failed

| make[2]: *** [proc-service.o] Error 1

| make[2]: *** Waiting for unfinished jobs....

| In file included from ../../gdb-7.7.1/gdb/linux-thread-db.c:24:0:

| ../../gdb-7.7.1/gdb/gdb_proc_service.h:162:9: error: unknown type name 'gdb_fpregset_t'

|  typedef gdb_fpregset_t gdb_prfpregset_t;

|          ^~~~~~~~~~~~~~

| Makefile:1011: recipe for target 'linux-thread-db.o' failed

| make[2]: *** [linux-thread-db.o] Error 1

| make[2]: Leaving directory '/opt/yocto/yocto-bwc/builds/microblazeel/tmp/work/microblazeel-v9.6-bs-cmp-mh-poky-linux/gdb/7.7.1-r0/build-microblazeel-poky-linux/gdb'

| Makefile:8278: recipe for target 'all-gdb' failed

| make[1]: *** [all-gdb] Error 2

| make[1]: Leaving directory '/opt/yocto/yocto-bwc/builds/microblazeel/tmp/work/microblazeel-v9.6-bs-cmp-mh-poky-linux/gdb/7.7.1-r0/build-microblazeel-poky-linux'

| Makefile:832: recipe for target 'all' failed

| make: *** [all] Error 2

| WARNING: /opt/yocto/yocto-bwc/builds/microblazeel/tmp/work/microblazeel-v9.6-bs-cmp-mh-poky-linux/gdb/7.7.1-r0/temp/run.do_compile.18533:1exit 1 from 'exit 1'

| ERROR: Function failed: do_compile (log file is located at /opt/yocto/yocto-bwc/builds/microblazeel/tmp/work/microblazeel-v9.6-bs-cmp-mh-poky-linux/gdb/7.7.1-r0/temp/log.do_compile.18533)

ERROR: Task (/opt/yocto/poky/meta-xilinx/recipes-microblaze/gdb/gdb_7.7.1.bb:do_compile) failed with exit code '1'

 


Re: Recipe do_install priority

Khem Raj
 

On 6/5/20 5:51 AM, Laurent Gauthier wrote:
Hi Mauro, all,
During the creation of the rootfs of your image yocto will try to install both packages, and should complain loudly because the same file is provided by two packages.
There are a few ways you can do this properly:
a) the straight-forware way is be to create a bbappend for init-ifupdown that updates the contentious file with the content that you need, and NOT provide this file in your library.bb <http://library.bb>
this is best course of action, for maintainance POV as well as readability, I know of custom packages that bundled bits and pieces into a single package like this and call it some meta package but ideally, its better to stay with upstream packaging conventions. Its less work eventually to maintain.

b) you could also createa bbappend for init-ifupdown which remove that file from the installation in a do_install_append, and then you are free to install it in your library.bb <http://library.bb> as it is not longer part of init-ifupdown. This is not too complex.
c) another option is to try to use alternatives which allows the same file to be delivered by several packages, and which one is used is selected at install and/or runtime by using symbolic links (example: vi vs vim). This requires a bit more research.
I am afraid that options other than these straight-forward ones will qualify for the title of "horrible hacks"... :-)
Kind regards, Laurent.
On Fri, Jun 5, 2020 at 1:31 PM Mauro Ziliani <mauro@faresoftware.it <mailto:mauro@faresoftware.it>> wrote:
Hi all.
I'm Mauro.
I have to resolve this matter.
The recipe init-ifupdown.bb <http://init-ifupdown.bb> install file
interfaces in /etc/network.
I build a library which need to install the same file in the same
folder.
This library is managed by its own recipe library.bb
<http://library.bb> in my meta-mylayer.
How can I tell to bitbake to install library after init-ifupdown in
final image?
The best for me should be drive this behavoir in the recipe-image.bb
<http://recipe-image.bb> in
this way
library:do_install after init-ifupdown:do_install
that means  run do_install of library.bb <http://library.bb> afger
do_install of
init-ifupdown.bb <http://init-ifupdown.bb>
Any idea?
MZ
--
Laurent Gauthier
Embedded Linux Systems & Software
Phone: +33 630 483 429
http://soccasys.com


SDK using meta-mingw: missing. rm.exe

Lukasz Domowy
 

Hello,

I am building SDK for Windows host using meta-mingw (bitbake image -c
populate_sdk). That SDK will be given to customer and it should be
self-contained - contain all binaries required to perform make-style
builds.

I was able to add make.exe by adding following to local.conf file:
TOOLCHAIN_HOST_TASK_append = "${SDK_EXTRA_TOOLS}"
SDK_EXTRA_TOOLS += " nativesdk-make "

What should I do to build and add rm.exe to SDK?

Best regards,
Lukasz


SDK: generate license manifest

Lukasz Domowy
 

Hello,

I am building SDK (bitbake image -c populate_sdk). Those SDK binaries
will be given to customer.
How can I generate license manifest file (open source disclosure)?

I can see *.manifest files for host and target, but they miss license
types and license texts.

Best regards,
Lukasz


Re: Recipe do_install priority

Laurent Gauthier
 

Hi Mauro, all,

During the creation of the rootfs of your image yocto will try to install both packages, and should complain loudly because the same file is provided by two packages.

There are a few ways you can do this properly:

a) the straight-forware way is be to create a bbappend for init-ifupdown that updates the contentious file with the content that you need, and NOT provide this file in your library.bb

b) you could also createa bbappend for init-ifupdown which remove that file from the installation in a do_install_append, and then you are free to install it in your library.bb as it is not longer part of init-ifupdown. This is not too complex.

c) another option is to try to use alternatives which allows the same file to be delivered by several packages, and which one is used is selected at install and/or runtime by using symbolic links (example: vi vs vim). This requires a bit more research.

I am afraid that options other than these straight-forward ones will qualify for the title of "horrible hacks"... :-)

Kind regards, Laurent.


On Fri, Jun 5, 2020 at 1:31 PM Mauro Ziliani <mauro@...> wrote:
Hi all.

I'm Mauro.

I have to resolve this matter.

The recipe  init-ifupdown.bb install file interfaces in /etc/network.


I build a library which need to install the same file in the same folder.

This library is managed by its own recipe  library.bb in my meta-mylayer.


How can I tell to bitbake to install library after init-ifupdown in
final image?


The best for me should be drive this behavoir in the recipe-image.bb in
this way


library:do_install after init-ifupdown:do_install


that means  run do_install of library.bb afger do_install of
init-ifupdown.bb


Any idea?


MZ




--
Laurent Gauthier
Embedded Linux Systems & Software
Phone: +33 630 483 429
http://soccasys.com


Re: Recipe do_install priority

Alexander Kanavin
 

do_install() is not installing things into the final image. It is installing items to the target location under a separate 'destination directory', independently of anything else that installs to the same target location under different destination directory. If the filenames are the same, you will get a file conflict error later on when the image is constructed.

It would help if you describe in detail what file do you intend to replace, and why.

Alex


On Fri, 5 Jun 2020 at 13:31, Mauro Ziliani <mauro@...> wrote:
Hi all.

I'm Mauro.

I have to resolve this matter.

The recipe  init-ifupdown.bb install file interfaces in /etc/network.


I build a library which need to install the same file in the same folder.

This library is managed by its own recipe  library.bb in my meta-mylayer.


How can I tell to bitbake to install library after init-ifupdown in
final image?


The best for me should be drive this behavoir in the recipe-image.bb in
this way


library:do_install after init-ifupdown:do_install


that means  run do_install of library.bb afger do_install of
init-ifupdown.bb


Any idea?


MZ



Recipe do_install priority

Mauro Ziliani
 

Hi all.

I'm Mauro.

I have to resolve this matter.

The recipe  init-ifupdown.bb install file interfaces in /etc/network.


I build a library which need to install the same file in the same folder.

This library is managed by its own recipe  library.bb in my meta-mylayer.


How can I tell to bitbake to install library after init-ifupdown in final image?


The best for me should be drive this behavoir in the recipe-image.bb in this way


library:do_install after init-ifupdown:do_install


that means  run do_install of library.bb afger do_install of init-ifupdown.bb


Any idea?


MZ


Re: opkg package manifest file is not generated by bitbake

Kevin Kettinger
 

Worked, thank you!

Mit freundlichen Grüßen / Best regards,
Kevin Kettinger

Am 05.06.2020 um 08:53 schrieb Denys Dmytriyenko:

bitbake package-index
On Fri, Jun 05, 2020 at 08:48:22AM +0200, Kevin Kettinger wrote:
Hello,

i want to use my yocto build sever as opkg package source for
updating some packages directly, but it seems after generating an
image the "Packages" file for opkg is not created.

In the ./<build>/tmp/deploy/ipk folder, there are these folders
---------------------------------------------------------------------
all
apalis_imx6
cortexa9hf-neon
cortexa9t2hf-neon
cortexa9t2hf-neon-mx6qdl
---------------------------------------------------------------------
but no "Packages" or "Packages.gz" file.

My local.conf:
---------------------------------------------------------------------
BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"
PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"
MACHINE ??= "apalis-imx6"
MACHINE_HOSTNAME ?= "b2qt-${MACHINE}"
DL_DIR ?= "${TOPDIR}/../downloads"
SSTATE_DIR ?= "${TOPDIR}/../sstate-cache"
DISTRO ?= "b2qt"
PACKAGE_CLASSES ?= "package_ipk"
EXTRA_IMAGE_FEATURES = "debug-tweaks"
USER_CLASSES ?= "buildstats image-mklibs"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS = "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
ABORT,${TMPDIR},100M,1K \
ABORT,${DL_DIR},100M,1K \
ABORT,${SSTATE_DIR},100M,1K"
CONF_VERSION = "1"
INHERIT += "image-buildinfo"
INHERIT += "internal-build"
ACCEPT_FSL_EULA = "1"
LICENSE_FLAGS_WHITELIST = "commercial"
QT_SDK_PATH = ""
PRSERV_HOST = "localhost:0"
include conf/distro/include/${MACHINE}.pre.inc
INHERIT+="toaster buildhistory"
BUILDHISTORY_COMMIT = "1"
---------------------------------------------------------------------

My image.bb file does provider "package-management":
---------------------------------------------------------------------
IMAGE_FEATURES += "\
package-management \
ssh-server-dropbear \
tools-debug \
tools-profile \
debug-tweaks \
hwcodecs \
"
---------------------------------------------------------------------
(opkg is working on the embedded device)

Output after building an image:
---------------------------------------------------------------------
BB_VERSION = "1.42.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "arm-poky-linux-gnueabi"
MACHINE = "apalis-imx6"
DISTRO = "b2qt"
DISTRO_VERSION = "2.7.3"
TUNE_FEATURES = "arm vfp cortexa9 neon thumb callconvention-hard"
TARGET_FPU = "hard"
SDKMACHINE = "x86_64"
---------------------------------------------------------------------

A appreciate any help.

Mit freundlichen Grüßen / Best regards,
Kevin Kettinger


Re: opkg package manifest file is not generated by bitbake

Denys Dmytriyenko
 

bitbake package-index

On Fri, Jun 05, 2020 at 08:48:22AM +0200, Kevin Kettinger wrote:
Hello,

i want to use my yocto build sever as opkg package source for
updating some packages directly, but it seems after generating an
image the "Packages" file for opkg is not created.

In the ./<build>/tmp/deploy/ipk folder, there are these folders
---------------------------------------------------------------------
all
apalis_imx6
cortexa9hf-neon
cortexa9t2hf-neon
cortexa9t2hf-neon-mx6qdl
---------------------------------------------------------------------
but no "Packages" or "Packages.gz" file.

My local.conf:
---------------------------------------------------------------------
BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"
PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"
MACHINE ??= "apalis-imx6"
MACHINE_HOSTNAME ?= "b2qt-${MACHINE}"
DL_DIR ?= "${TOPDIR}/../downloads"
SSTATE_DIR ?= "${TOPDIR}/../sstate-cache"
DISTRO ?= "b2qt"
PACKAGE_CLASSES ?= "package_ipk"
EXTRA_IMAGE_FEATURES = "debug-tweaks"
USER_CLASSES ?= "buildstats image-mklibs"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS = "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
ABORT,${TMPDIR},100M,1K \
ABORT,${DL_DIR},100M,1K \
ABORT,${SSTATE_DIR},100M,1K"
CONF_VERSION = "1"
INHERIT += "image-buildinfo"
INHERIT += "internal-build"
ACCEPT_FSL_EULA = "1"
LICENSE_FLAGS_WHITELIST = "commercial"
QT_SDK_PATH = ""
PRSERV_HOST = "localhost:0"
include conf/distro/include/${MACHINE}.pre.inc
INHERIT+="toaster buildhistory"
BUILDHISTORY_COMMIT = "1"
---------------------------------------------------------------------

My image.bb file does provider "package-management":
---------------------------------------------------------------------
IMAGE_FEATURES += "\
package-management \
ssh-server-dropbear \
tools-debug \
tools-profile \
debug-tweaks \
hwcodecs \
"
---------------------------------------------------------------------
(opkg is working on the embedded device)

Output after building an image:
---------------------------------------------------------------------
BB_VERSION = "1.42.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "arm-poky-linux-gnueabi"
MACHINE = "apalis-imx6"
DISTRO = "b2qt"
DISTRO_VERSION = "2.7.3"
TUNE_FEATURES = "arm vfp cortexa9 neon thumb callconvention-hard"
TARGET_FPU = "hard"
SDKMACHINE = "x86_64"
---------------------------------------------------------------------

A appreciate any help.

Mit freundlichen Grüßen / Best regards,
Kevin Kettinger


opkg package manifest file is not generated by bitbake

Kevin Kettinger
 

Hello,

i want to use my yocto build sever as opkg package source for updating some packages directly, but it seems after generating an image the "Packages" file for opkg is not created.

In the ./<build>/tmp/deploy/ipk folder, there are these folders
---------------------------------------------------------------------
all
apalis_imx6
cortexa9hf-neon
cortexa9t2hf-neon
cortexa9t2hf-neon-mx6qdl
---------------------------------------------------------------------
but no "Packages" or "Packages.gz" file.

My local.conf:
---------------------------------------------------------------------
BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"
PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"
MACHINE ??= "apalis-imx6"
MACHINE_HOSTNAME ?= "b2qt-${MACHINE}"
DL_DIR ?= "${TOPDIR}/../downloads"
SSTATE_DIR ?= "${TOPDIR}/../sstate-cache"
DISTRO ?= "b2qt"
PACKAGE_CLASSES ?= "package_ipk"
EXTRA_IMAGE_FEATURES = "debug-tweaks"
USER_CLASSES ?= "buildstats image-mklibs"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS = "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
ABORT,${TMPDIR},100M,1K \
ABORT,${DL_DIR},100M,1K \
ABORT,${SSTATE_DIR},100M,1K"
CONF_VERSION = "1"
INHERIT += "image-buildinfo"
INHERIT += "internal-build"
ACCEPT_FSL_EULA = "1"
LICENSE_FLAGS_WHITELIST = "commercial"
QT_SDK_PATH = ""
PRSERV_HOST = "localhost:0"
include conf/distro/include/${MACHINE}.pre.inc
INHERIT+="toaster buildhistory"
BUILDHISTORY_COMMIT = "1"
---------------------------------------------------------------------

My image.bb file does provider "package-management":
---------------------------------------------------------------------
IMAGE_FEATURES += "\
package-management \
ssh-server-dropbear \
tools-debug \
tools-profile \
debug-tweaks \
hwcodecs \
"
---------------------------------------------------------------------
(opkg is working on the embedded device)

Output after building an image:
---------------------------------------------------------------------
BB_VERSION = "1.42.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "arm-poky-linux-gnueabi"
MACHINE = "apalis-imx6"
DISTRO = "b2qt"
DISTRO_VERSION = "2.7.3"
TUNE_FEATURES = "arm vfp cortexa9 neon thumb callconvention-hard"
TARGET_FPU = "hard"
SDKMACHINE = "x86_64"
---------------------------------------------------------------------

A appreciate any help.

Mit freundlichen Grüßen / Best regards,
Kevin Kettinger


Stable Warrior branch

Armin Kuster
 

Hello,

The Warrior branch of Poky has had its last official dot release. It
will be moving to Community support and EOL within 6 weeks if no one
steps up.
If someone is interested in taking on the responsibilities of
maintaining the "Warrior" branch moving forward, please email this list.

Please look at the
https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS for what will
be expected.

regards,
Armin


[meta-selinux][PATCH] libsepol: fix build errors on Fedora 32

Yi Zhao
 

Backport 2 patches to fix the build errors on Fedora 32.

Fixes:
[snip]
../cil/src/cil_verify.lo:(.bss+0x4f0): multiple definition of `CIL_KEY_CONS_T3';
../cil/src/cil_verify.lo:(.bss+0x4f8): multiple definition of `CIL_KEY_CONS_T2';
../cil/src/cil_verify.lo:(.bss+0x500): multiple definition of `CIL_KEY_CONS_T1';
../cil/src/cil_verify.lo:(.bss+0x508): multiple definition of `cil_mem_error_handler';
[snip]

Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
---
...IL_KEY_-build-errors-with-fno-common.patch | 530 ++++++++++++++++++
...e-leftovers-of-cil_mem_error_handler.patch | 65 +++
recipes-security/selinux/libsepol_3.0.bb | 5 +
3 files changed, 600 insertions(+)
create mode 100644 recipes-security/selinux/libsepol/0001-libsepol-fix-CIL_KEY_-build-errors-with-fno-common.patch
create mode 100644 recipes-security/selinux/libsepol/0001-libsepol-remove-leftovers-of-cil_mem_error_handler.patch

diff --git a/recipes-security/selinux/libsepol/0001-libsepol-fix-CIL_KEY_-build-errors-with-fno-common.patch b/recipes-security/selinux/libsepol/0001-libsepol-fix-CIL_KEY_-build-errors-with-fno-common.patch
new file mode 100644
index 0000000..46c56a4
--- /dev/null
+++ b/recipes-security/selinux/libsepol/0001-libsepol-fix-CIL_KEY_-build-errors-with-fno-common.patch
@@ -0,0 +1,530 @@
+From a96e8c59ecac84096d870b42701a504791a8cc8c Mon Sep 17 00:00:00 2001
+From: Ondrej Mosnacek <omosnace@redhat.com>
+Date: Thu, 23 Jan 2020 13:57:13 +0100
+Subject: [PATCH] libsepol: fix CIL_KEY_* build errors with -fno-common
+
+GCC 10 comes with -fno-common enabled by default - fix the CIL_KEY_*
+global variables to be defined only once in cil.c and declared in the
+header file correctly with the 'extern' keyword, so that other units
+including the file don't generate duplicate definitions.
+
+Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
+
+Upstream-Status: Backport
+[https://github.com/SELinuxProject/selinux/commit/a96e8c59ecac84096d870b42701a504791a8cc8c]
+
+Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
+---
+ cil/src/cil.c | 162 ++++++++++++++++
+ cil/src/cil_internal.h | 322 ++++++++++++++++----------------
+ 2 files changed, 323 insertions(+), 161 deletions(-)
+
+diff --git a/cil/src/cil.c b/cil/src/cil.c
+index de729cf8..d222ad3a 100644
+--- a/cil/src/cil.c
++++ b/cil/src/cil.c
+@@ -77,6 +77,168 @@ int cil_sym_sizes[CIL_SYM_ARRAY_NUM][CIL_SYM_NUM] = {
+ {1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1}
+ };
+
++char *CIL_KEY_CONS_T1;
++char *CIL_KEY_CONS_T2;
++char *CIL_KEY_CONS_T3;
++char *CIL_KEY_CONS_R1;
++char *CIL_KEY_CONS_R2;
++char *CIL_KEY_CONS_R3;
++char *CIL_KEY_CONS_U1;
++char *CIL_KEY_CONS_U2;
++char *CIL_KEY_CONS_U3;
++char *CIL_KEY_CONS_L1;
++char *CIL_KEY_CONS_L2;
++char *CIL_KEY_CONS_H1;
++char *CIL_KEY_CONS_H2;
++char *CIL_KEY_AND;
++char *CIL_KEY_OR;
++char *CIL_KEY_NOT;
++char *CIL_KEY_EQ;
++char *CIL_KEY_NEQ;
++char *CIL_KEY_CONS_DOM;
++char *CIL_KEY_CONS_DOMBY;
++char *CIL_KEY_CONS_INCOMP;
++char *CIL_KEY_CONDTRUE;
++char *CIL_KEY_CONDFALSE;
++char *CIL_KEY_SELF;
++char *CIL_KEY_OBJECT_R;
++char *CIL_KEY_STAR;
++char *CIL_KEY_TCP;
++char *CIL_KEY_UDP;
++char *CIL_KEY_DCCP;
++char *CIL_KEY_SCTP;
++char *CIL_KEY_AUDITALLOW;
++char *CIL_KEY_TUNABLEIF;
++char *CIL_KEY_ALLOW;
++char *CIL_KEY_DONTAUDIT;
++char *CIL_KEY_TYPETRANSITION;
++char *CIL_KEY_TYPECHANGE;
++char *CIL_KEY_CALL;
++char *CIL_KEY_TUNABLE;
++char *CIL_KEY_XOR;
++char *CIL_KEY_ALL;
++char *CIL_KEY_RANGE;
++char *CIL_KEY_GLOB;
++char *CIL_KEY_FILE;
++char *CIL_KEY_DIR;
++char *CIL_KEY_CHAR;
++char *CIL_KEY_BLOCK;
++char *CIL_KEY_SOCKET;
++char *CIL_KEY_PIPE;
++char *CIL_KEY_SYMLINK;
++char *CIL_KEY_ANY;
++char *CIL_KEY_XATTR;
++char *CIL_KEY_TASK;
++char *CIL_KEY_TRANS;
++char *CIL_KEY_TYPE;
++char *CIL_KEY_ROLE;
++char *CIL_KEY_USER;
++char *CIL_KEY_USERATTRIBUTE;
++char *CIL_KEY_USERATTRIBUTESET;
++char *CIL_KEY_SENSITIVITY;
++char *CIL_KEY_CATEGORY;
++char *CIL_KEY_CATSET;
++char *CIL_KEY_LEVEL;
++char *CIL_KEY_LEVELRANGE;
++char *CIL_KEY_CLASS;
++char *CIL_KEY_IPADDR;
++char *CIL_KEY_MAP_CLASS;
++char *CIL_KEY_CLASSPERMISSION;
++char *CIL_KEY_BOOL;
++char *CIL_KEY_STRING;
++char *CIL_KEY_NAME;
++char *CIL_KEY_SOURCE;
++char *CIL_KEY_TARGET;
++char *CIL_KEY_LOW;
++char *CIL_KEY_HIGH;
++char *CIL_KEY_LOW_HIGH;
++char *CIL_KEY_GLBLUB;
++char *CIL_KEY_HANDLEUNKNOWN;
++char *CIL_KEY_HANDLEUNKNOWN_ALLOW;
++char *CIL_KEY_HANDLEUNKNOWN_DENY;
++char *CIL_KEY_HANDLEUNKNOWN_REJECT;
++char *CIL_KEY_MACRO;
++char *CIL_KEY_IN;
++char *CIL_KEY_MLS;
++char *CIL_KEY_DEFAULTRANGE;
++char *CIL_KEY_BLOCKINHERIT;
++char *CIL_KEY_BLOCKABSTRACT;
++char *CIL_KEY_CLASSORDER;
++char *CIL_KEY_CLASSMAPPING;
++char *CIL_KEY_CLASSPERMISSIONSET;
++char *CIL_KEY_COMMON;
++char *CIL_KEY_CLASSCOMMON;
++char *CIL_KEY_SID;
++char *CIL_KEY_SIDCONTEXT;
++char *CIL_KEY_SIDORDER;
++char *CIL_KEY_USERLEVEL;
++char *CIL_KEY_USERRANGE;
++char *CIL_KEY_USERBOUNDS;
++char *CIL_KEY_USERPREFIX;
++char *CIL_KEY_SELINUXUSER;
++char *CIL_KEY_SELINUXUSERDEFAULT;
++char *CIL_KEY_TYPEATTRIBUTE;
++char *CIL_KEY_TYPEATTRIBUTESET;
++char *CIL_KEY_EXPANDTYPEATTRIBUTE;
++char *CIL_KEY_TYPEALIAS;
++char *CIL_KEY_TYPEALIASACTUAL;
++char *CIL_KEY_TYPEBOUNDS;
++char *CIL_KEY_TYPEPERMISSIVE;
++char *CIL_KEY_RANGETRANSITION;
++char *CIL_KEY_USERROLE;
++char *CIL_KEY_ROLETYPE;
++char *CIL_KEY_ROLETRANSITION;
++char *CIL_KEY_ROLEALLOW;
++char *CIL_KEY_ROLEATTRIBUTE;
++char *CIL_KEY_ROLEATTRIBUTESET;
++char *CIL_KEY_ROLEBOUNDS;
++char *CIL_KEY_BOOLEANIF;
++char *CIL_KEY_NEVERALLOW;
++char *CIL_KEY_TYPEMEMBER;
++char *CIL_KEY_SENSALIAS;
++char *CIL_KEY_SENSALIASACTUAL;
++char *CIL_KEY_CATALIAS;
++char *CIL_KEY_CATALIASACTUAL;
++char *CIL_KEY_CATORDER;
++char *CIL_KEY_SENSITIVITYORDER;
++char *CIL_KEY_SENSCAT;
++char *CIL_KEY_CONSTRAIN;
++char *CIL_KEY_MLSCONSTRAIN;
++char *CIL_KEY_VALIDATETRANS;
++char *CIL_KEY_MLSVALIDATETRANS;
++char *CIL_KEY_CONTEXT;
++char *CIL_KEY_FILECON;
++char *CIL_KEY_IBPKEYCON;
++char *CIL_KEY_IBENDPORTCON;
++char *CIL_KEY_PORTCON;
++char *CIL_KEY_NODECON;
++char *CIL_KEY_GENFSCON;
++char *CIL_KEY_NETIFCON;
++char *CIL_KEY_PIRQCON;
++char *CIL_KEY_IOMEMCON;
++char *CIL_KEY_IOPORTCON;
++char *CIL_KEY_PCIDEVICECON;
++char *CIL_KEY_DEVICETREECON;
++char *CIL_KEY_FSUSE;
++char *CIL_KEY_POLICYCAP;
++char *CIL_KEY_OPTIONAL;
++char *CIL_KEY_DEFAULTUSER;
++char *CIL_KEY_DEFAULTROLE;
++char *CIL_KEY_DEFAULTTYPE;
++char *CIL_KEY_ROOT;
++char *CIL_KEY_NODE;
++char *CIL_KEY_PERM;
++char *CIL_KEY_ALLOWX;
++char *CIL_KEY_AUDITALLOWX;
++char *CIL_KEY_DONTAUDITX;
++char *CIL_KEY_NEVERALLOWX;
++char *CIL_KEY_PERMISSIONX;
++char *CIL_KEY_IOCTL;
++char *CIL_KEY_UNORDERED;
++char *CIL_KEY_SRC_INFO;
++char *CIL_KEY_SRC_CIL;
++char *CIL_KEY_SRC_HLL;
++
+ static void cil_init_keys(void)
+ {
+ /* Initialize CIL Keys into strpool */
+diff --git a/cil/src/cil_internal.h b/cil/src/cil_internal.h
+index 30fab649..9bdcbdd0 100644
+--- a/cil/src/cil_internal.h
++++ b/cil/src/cil_internal.h
+@@ -74,167 +74,167 @@ enum cil_pass {
+ /*
+ Keywords
+ */
+-char *CIL_KEY_CONS_T1;
+-char *CIL_KEY_CONS_T2;
+-char *CIL_KEY_CONS_T3;
+-char *CIL_KEY_CONS_R1;
+-char *CIL_KEY_CONS_R2;
+-char *CIL_KEY_CONS_R3;
+-char *CIL_KEY_CONS_U1;
+-char *CIL_KEY_CONS_U2;
+-char *CIL_KEY_CONS_U3;
+-char *CIL_KEY_CONS_L1;
+-char *CIL_KEY_CONS_L2;
+-char *CIL_KEY_CONS_H1;
+-char *CIL_KEY_CONS_H2;
+-char *CIL_KEY_AND;
+-char *CIL_KEY_OR;
+-char *CIL_KEY_NOT;
+-char *CIL_KEY_EQ;
+-char *CIL_KEY_NEQ;
+-char *CIL_KEY_CONS_DOM;
+-char *CIL_KEY_CONS_DOMBY;
+-char *CIL_KEY_CONS_INCOMP;
+-char *CIL_KEY_CONDTRUE;
+-char *CIL_KEY_CONDFALSE;
+-char *CIL_KEY_SELF;
+-char *CIL_KEY_OBJECT_R;
+-char *CIL_KEY_STAR;
+-char *CIL_KEY_TCP;
+-char *CIL_KEY_UDP;
+-char *CIL_KEY_DCCP;
+-char *CIL_KEY_SCTP;
+-char *CIL_KEY_AUDITALLOW;
+-char *CIL_KEY_TUNABLEIF;
+-char *CIL_KEY_ALLOW;
+-char *CIL_KEY_DONTAUDIT;
+-char *CIL_KEY_TYPETRANSITION;
+-char *CIL_KEY_TYPECHANGE;
+-char *CIL_KEY_CALL;
+-char *CIL_KEY_TUNABLE;
+-char *CIL_KEY_XOR;
+-char *CIL_KEY_ALL;
+-char *CIL_KEY_RANGE;
+-char *CIL_KEY_GLOB;
+-char *CIL_KEY_FILE;
+-char *CIL_KEY_DIR;
+-char *CIL_KEY_CHAR;
+-char *CIL_KEY_BLOCK;
+-char *CIL_KEY_SOCKET;
+-char *CIL_KEY_PIPE;
+-char *CIL_KEY_SYMLINK;
+-char *CIL_KEY_ANY;
+-char *CIL_KEY_XATTR;
+-char *CIL_KEY_TASK;
+-char *CIL_KEY_TRANS;
+-char *CIL_KEY_TYPE;
+-char *CIL_KEY_ROLE;
+-char *CIL_KEY_USER;
+-char *CIL_KEY_USERATTRIBUTE;
+-char *CIL_KEY_USERATTRIBUTESET;
+-char *CIL_KEY_SENSITIVITY;
+-char *CIL_KEY_CATEGORY;
+-char *CIL_KEY_CATSET;
+-char *CIL_KEY_LEVEL;
+-char *CIL_KEY_LEVELRANGE;
+-char *CIL_KEY_CLASS;
+-char *CIL_KEY_IPADDR;
+-char *CIL_KEY_MAP_CLASS;
+-char *CIL_KEY_CLASSPERMISSION;
+-char *CIL_KEY_BOOL;
+-char *CIL_KEY_STRING;
+-char *CIL_KEY_NAME;
+-char *CIL_KEY_SOURCE;
+-char *CIL_KEY_TARGET;
+-char *CIL_KEY_LOW;
+-char *CIL_KEY_HIGH;
+-char *CIL_KEY_LOW_HIGH;
+-char *CIL_KEY_GLBLUB;
+-char *CIL_KEY_HANDLEUNKNOWN;
+-char *CIL_KEY_HANDLEUNKNOWN_ALLOW;
+-char *CIL_KEY_HANDLEUNKNOWN_DENY;
+-char *CIL_KEY_HANDLEUNKNOWN_REJECT;
+-char *CIL_KEY_MACRO;
+-char *CIL_KEY_IN;
+-char *CIL_KEY_MLS;
+-char *CIL_KEY_DEFAULTRANGE;
+-char *CIL_KEY_BLOCKINHERIT;
+-char *CIL_KEY_BLOCKABSTRACT;
+-char *CIL_KEY_CLASSORDER;
+-char *CIL_KEY_CLASSMAPPING;
+-char *CIL_KEY_CLASSPERMISSIONSET;
+-char *CIL_KEY_COMMON;
+-char *CIL_KEY_CLASSCOMMON;
+-char *CIL_KEY_SID;
+-char *CIL_KEY_SIDCONTEXT;
+-char *CIL_KEY_SIDORDER;
+-char *CIL_KEY_USERLEVEL;
+-char *CIL_KEY_USERRANGE;
+-char *CIL_KEY_USERBOUNDS;
+-char *CIL_KEY_USERPREFIX;
+-char *CIL_KEY_SELINUXUSER;
+-char *CIL_KEY_SELINUXUSERDEFAULT;
+-char *CIL_KEY_TYPEATTRIBUTE;
+-char *CIL_KEY_TYPEATTRIBUTESET;
+-char *CIL_KEY_EXPANDTYPEATTRIBUTE;
+-char *CIL_KEY_TYPEALIAS;
+-char *CIL_KEY_TYPEALIASACTUAL;
+-char *CIL_KEY_TYPEBOUNDS;
+-char *CIL_KEY_TYPEPERMISSIVE;
+-char *CIL_KEY_RANGETRANSITION;
+-char *CIL_KEY_USERROLE;
+-char *CIL_KEY_ROLETYPE;
+-char *CIL_KEY_ROLETRANSITION;
+-char *CIL_KEY_ROLEALLOW;
+-char *CIL_KEY_ROLEATTRIBUTE;
+-char *CIL_KEY_ROLEATTRIBUTESET;
+-char *CIL_KEY_ROLEBOUNDS;
+-char *CIL_KEY_BOOLEANIF;
+-char *CIL_KEY_NEVERALLOW;
+-char *CIL_KEY_TYPEMEMBER;
+-char *CIL_KEY_SENSALIAS;
+-char *CIL_KEY_SENSALIASACTUAL;
+-char *CIL_KEY_CATALIAS;
+-char *CIL_KEY_CATALIASACTUAL;
+-char *CIL_KEY_CATORDER;
+-char *CIL_KEY_SENSITIVITYORDER;
+-char *CIL_KEY_SENSCAT;
+-char *CIL_KEY_CONSTRAIN;
+-char *CIL_KEY_MLSCONSTRAIN;
+-char *CIL_KEY_VALIDATETRANS;
+-char *CIL_KEY_MLSVALIDATETRANS;
+-char *CIL_KEY_CONTEXT;
+-char *CIL_KEY_FILECON;
+-char *CIL_KEY_IBPKEYCON;
+-char *CIL_KEY_IBENDPORTCON;
+-char *CIL_KEY_PORTCON;
+-char *CIL_KEY_NODECON;
+-char *CIL_KEY_GENFSCON;
+-char *CIL_KEY_NETIFCON;
+-char *CIL_KEY_PIRQCON;
+-char *CIL_KEY_IOMEMCON;
+-char *CIL_KEY_IOPORTCON;
+-char *CIL_KEY_PCIDEVICECON;
+-char *CIL_KEY_DEVICETREECON;
+-char *CIL_KEY_FSUSE;
+-char *CIL_KEY_POLICYCAP;
+-char *CIL_KEY_OPTIONAL;
+-char *CIL_KEY_DEFAULTUSER;
+-char *CIL_KEY_DEFAULTROLE;
+-char *CIL_KEY_DEFAULTTYPE;
+-char *CIL_KEY_ROOT;
+-char *CIL_KEY_NODE;
+-char *CIL_KEY_PERM;
+-char *CIL_KEY_ALLOWX;
+-char *CIL_KEY_AUDITALLOWX;
+-char *CIL_KEY_DONTAUDITX;
+-char *CIL_KEY_NEVERALLOWX;
+-char *CIL_KEY_PERMISSIONX;
+-char *CIL_KEY_IOCTL;
+-char *CIL_KEY_UNORDERED;
+-char *CIL_KEY_SRC_INFO;
+-char *CIL_KEY_SRC_CIL;
+-char *CIL_KEY_SRC_HLL;
++extern char *CIL_KEY_CONS_T1;
++extern char *CIL_KEY_CONS_T2;
++extern char *CIL_KEY_CONS_T3;
++extern char *CIL_KEY_CONS_R1;
++extern char *CIL_KEY_CONS_R2;
++extern char *CIL_KEY_CONS_R3;
++extern char *CIL_KEY_CONS_U1;
++extern char *CIL_KEY_CONS_U2;
++extern char *CIL_KEY_CONS_U3;
++extern char *CIL_KEY_CONS_L1;
++extern char *CIL_KEY_CONS_L2;
++extern char *CIL_KEY_CONS_H1;
++extern char *CIL_KEY_CONS_H2;
++extern char *CIL_KEY_AND;
++extern char *CIL_KEY_OR;
++extern char *CIL_KEY_NOT;
++extern char *CIL_KEY_EQ;
++extern char *CIL_KEY_NEQ;
++extern char *CIL_KEY_CONS_DOM;
++extern char *CIL_KEY_CONS_DOMBY;
++extern char *CIL_KEY_CONS_INCOMP;
++extern char *CIL_KEY_CONDTRUE;
++extern char *CIL_KEY_CONDFALSE;
++extern char *CIL_KEY_SELF;
++extern char *CIL_KEY_OBJECT_R;
++extern char *CIL_KEY_STAR;
++extern char *CIL_KEY_TCP;
++extern char *CIL_KEY_UDP;
++extern char *CIL_KEY_DCCP;
++extern char *CIL_KEY_SCTP;
++extern char *CIL_KEY_AUDITALLOW;
++extern char *CIL_KEY_TUNABLEIF;
++extern char *CIL_KEY_ALLOW;
++extern char *CIL_KEY_DONTAUDIT;
++extern char *CIL_KEY_TYPETRANSITION;
++extern char *CIL_KEY_TYPECHANGE;
++extern char *CIL_KEY_CALL;
++extern char *CIL_KEY_TUNABLE;
++extern char *CIL_KEY_XOR;
++extern char *CIL_KEY_ALL;
++extern char *CIL_KEY_RANGE;
++extern char *CIL_KEY_GLOB;
++extern char *CIL_KEY_FILE;
++extern char *CIL_KEY_DIR;
++extern char *CIL_KEY_CHAR;
++extern char *CIL_KEY_BLOCK;
++extern char *CIL_KEY_SOCKET;
++extern char *CIL_KEY_PIPE;
++extern char *CIL_KEY_SYMLINK;
++extern char *CIL_KEY_ANY;
++extern char *CIL_KEY_XATTR;
++extern char *CIL_KEY_TASK;
++extern char *CIL_KEY_TRANS;
++extern char *CIL_KEY_TYPE;
++extern char *CIL_KEY_ROLE;
++extern char *CIL_KEY_USER;
++extern char *CIL_KEY_USERATTRIBUTE;
++extern char *CIL_KEY_USERATTRIBUTESET;
++extern char *CIL_KEY_SENSITIVITY;
++extern char *CIL_KEY_CATEGORY;
++extern char *CIL_KEY_CATSET;
++extern char *CIL_KEY_LEVEL;
++extern char *CIL_KEY_LEVELRANGE;
++extern char *CIL_KEY_CLASS;
++extern char *CIL_KEY_IPADDR;
++extern char *CIL_KEY_MAP_CLASS;
++extern char *CIL_KEY_CLASSPERMISSION;
++extern char *CIL_KEY_BOOL;
++extern char *CIL_KEY_STRING;
++extern char *CIL_KEY_NAME;
++extern char *CIL_KEY_SOURCE;
++extern char *CIL_KEY_TARGET;
++extern char *CIL_KEY_LOW;
++extern char *CIL_KEY_HIGH;
++extern char *CIL_KEY_LOW_HIGH;
++extern char *CIL_KEY_GLBLUB;
++extern char *CIL_KEY_HANDLEUNKNOWN;
++extern char *CIL_KEY_HANDLEUNKNOWN_ALLOW;
++extern char *CIL_KEY_HANDLEUNKNOWN_DENY;
++extern char *CIL_KEY_HANDLEUNKNOWN_REJECT;
++extern char *CIL_KEY_MACRO;
++extern char *CIL_KEY_IN;
++extern char *CIL_KEY_MLS;
++extern char *CIL_KEY_DEFAULTRANGE;
++extern char *CIL_KEY_BLOCKINHERIT;
++extern char *CIL_KEY_BLOCKABSTRACT;
++extern char *CIL_KEY_CLASSORDER;
++extern char *CIL_KEY_CLASSMAPPING;
++extern char *CIL_KEY_CLASSPERMISSIONSET;
++extern char *CIL_KEY_COMMON;
++extern char *CIL_KEY_CLASSCOMMON;
++extern char *CIL_KEY_SID;
++extern char *CIL_KEY_SIDCONTEXT;
++extern char *CIL_KEY_SIDORDER;
++extern char *CIL_KEY_USERLEVEL;
++extern char *CIL_KEY_USERRANGE;
++extern char *CIL_KEY_USERBOUNDS;
++extern char *CIL_KEY_USERPREFIX;
++extern char *CIL_KEY_SELINUXUSER;
++extern char *CIL_KEY_SELINUXUSERDEFAULT;
++extern char *CIL_KEY_TYPEATTRIBUTE;
++extern char *CIL_KEY_TYPEATTRIBUTESET;
++extern char *CIL_KEY_EXPANDTYPEATTRIBUTE;
++extern char *CIL_KEY_TYPEALIAS;
++extern char *CIL_KEY_TYPEALIASACTUAL;
++extern char *CIL_KEY_TYPEBOUNDS;
++extern char *CIL_KEY_TYPEPERMISSIVE;
++extern char *CIL_KEY_RANGETRANSITION;
++extern char *CIL_KEY_USERROLE;
++extern char *CIL_KEY_ROLETYPE;
++extern char *CIL_KEY_ROLETRANSITION;
++extern char *CIL_KEY_ROLEALLOW;
++extern char *CIL_KEY_ROLEATTRIBUTE;
++extern char *CIL_KEY_ROLEATTRIBUTESET;
++extern char *CIL_KEY_ROLEBOUNDS;
++extern char *CIL_KEY_BOOLEANIF;
++extern char *CIL_KEY_NEVERALLOW;
++extern char *CIL_KEY_TYPEMEMBER;
++extern char *CIL_KEY_SENSALIAS;
++extern char *CIL_KEY_SENSALIASACTUAL;
++extern char *CIL_KEY_CATALIAS;
++extern char *CIL_KEY_CATALIASACTUAL;
++extern char *CIL_KEY_CATORDER;
++extern char *CIL_KEY_SENSITIVITYORDER;
++extern char *CIL_KEY_SENSCAT;
++extern char *CIL_KEY_CONSTRAIN;
++extern char *CIL_KEY_MLSCONSTRAIN;
++extern char *CIL_KEY_VALIDATETRANS;
++extern char *CIL_KEY_MLSVALIDATETRANS;
++extern char *CIL_KEY_CONTEXT;
++extern char *CIL_KEY_FILECON;
++extern char *CIL_KEY_IBPKEYCON;
++extern char *CIL_KEY_IBENDPORTCON;
++extern char *CIL_KEY_PORTCON;
++extern char *CIL_KEY_NODECON;
++extern char *CIL_KEY_GENFSCON;
++extern char *CIL_KEY_NETIFCON;
++extern char *CIL_KEY_PIRQCON;
++extern char *CIL_KEY_IOMEMCON;
++extern char *CIL_KEY_IOPORTCON;
++extern char *CIL_KEY_PCIDEVICECON;
++extern char *CIL_KEY_DEVICETREECON;
++extern char *CIL_KEY_FSUSE;
++extern char *CIL_KEY_POLICYCAP;
++extern char *CIL_KEY_OPTIONAL;
++extern char *CIL_KEY_DEFAULTUSER;
++extern char *CIL_KEY_DEFAULTROLE;
++extern char *CIL_KEY_DEFAULTTYPE;
++extern char *CIL_KEY_ROOT;
++extern char *CIL_KEY_NODE;
++extern char *CIL_KEY_PERM;
++extern char *CIL_KEY_ALLOWX;
++extern char *CIL_KEY_AUDITALLOWX;
++extern char *CIL_KEY_DONTAUDITX;
++extern char *CIL_KEY_NEVERALLOWX;
++extern char *CIL_KEY_PERMISSIONX;
++extern char *CIL_KEY_IOCTL;
++extern char *CIL_KEY_UNORDERED;
++extern char *CIL_KEY_SRC_INFO;
++extern char *CIL_KEY_SRC_CIL;
++extern char *CIL_KEY_SRC_HLL;
+
+ /*
+ Symbol Table Array Indices
+--
+2.17.1
+
diff --git a/recipes-security/selinux/libsepol/0001-libsepol-remove-leftovers-of-cil_mem_error_handler.patch b/recipes-security/selinux/libsepol/0001-libsepol-remove-leftovers-of-cil_mem_error_handler.patch
new file mode 100644
index 0000000..674fddd
--- /dev/null
+++ b/recipes-security/selinux/libsepol/0001-libsepol-remove-leftovers-of-cil_mem_error_handler.patch
@@ -0,0 +1,65 @@
+From 3d32fc24d6aff360a538c63dad08ca5c957551b0 Mon Sep 17 00:00:00 2001
+From: Ondrej Mosnacek <omosnace@redhat.com>
+Date: Thu, 23 Jan 2020 13:57:14 +0100
+Subject: [PATCH] libsepol: remove leftovers of cil_mem_error_handler
+
+Commit 4459d635b8f1 ("libsepol: Remove cil_mem_error_handler() function
+pointer") replaced cil_mem_error_handler usage with inline contents of
+the default handler. However, it left over the header declaration and
+two callers. Convert these as well and remove the header declaration.
+
+This also fixes a build failure with -fno-common.
+
+Fixes: 4459d635b8f1 ("libsepol: Remove cil_mem_error_handler() function pointer")
+Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
+
+Upstream-Status: Backport
+[https://github.com/SELinuxProject/selinux/commit/3d32fc24d6aff360a538c63dad08ca5c957551b0]
+
+Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
+---
+ cil/src/cil_mem.h | 1 -
+ cil/src/cil_strpool.c | 8 ++++----
+ 2 files changed, 4 insertions(+), 5 deletions(-)
+
+diff --git a/cil/src/cil_mem.h b/cil/src/cil_mem.h
+index 902ce131..794f02a3 100644
+--- a/cil/src/cil_mem.h
++++ b/cil/src/cil_mem.h
+@@ -36,7 +36,6 @@ void *cil_calloc(size_t num_elements, size_t element_size);
+ void *cil_realloc(void *ptr, size_t size);
+ char *cil_strdup(const char *str);
+ int cil_asprintf(char **strp, const char *fmt, ...);
+-void (*cil_mem_error_handler)(void);
+
+ #endif /* CIL_MEM_H_ */
+
+diff --git a/cil/src/cil_strpool.c b/cil/src/cil_strpool.c
+index 97d4c4b9..2598bbf3 100644
+--- a/cil/src/cil_strpool.c
++++ b/cil/src/cil_strpool.c
+@@ -80,8 +80,8 @@ char *cil_strpool_add(const char *str)
+ int rc = hashtab_insert(cil_strpool_tab, (hashtab_key_t)strpool_ref->str, strpool_ref);
+ if (rc != SEPOL_OK) {
+ pthread_mutex_unlock(&cil_strpool_mutex);
+- (*cil_mem_error_handler)();
+- pthread_mutex_lock(&cil_strpool_mutex);
++ cil_log(CIL_ERR, "Failed to allocate memory\n");
++ exit(1);
+ }
+ }
+
+@@ -104,8 +104,8 @@ void cil_strpool_init(void)
+ cil_strpool_tab = hashtab_create(cil_strpool_hash, cil_strpool_compare, CIL_STRPOOL_TABLE_SIZE);
+ if (cil_strpool_tab == NULL) {
+ pthread_mutex_unlock(&cil_strpool_mutex);
+- (*cil_mem_error_handler)();
+- return;
++ cil_log(CIL_ERR, "Failed to allocate memory\n");
++ exit(1);
+ }
+ }
+ cil_strpool_readers++;
+--
+2.17.1
+
diff --git a/recipes-security/selinux/libsepol_3.0.bb b/recipes-security/selinux/libsepol_3.0.bb
index 6c85256..58559d7 100644
--- a/recipes-security/selinux/libsepol_3.0.bb
+++ b/recipes-security/selinux/libsepol_3.0.bb
@@ -5,3 +5,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343"

SRC_URI[md5sum] = "22ddb9994910cb9cfff5cb9663cb7ae7"
SRC_URI[sha256sum] = "5b7ae1881909f1048b06f7a0c364c5c8a86ec12e0ec76e740fe9595a6033eb79"
+
+SRC_URI += "\
+ file://0001-libsepol-fix-CIL_KEY_-build-errors-with-fno-common.patch \
+ file://0001-libsepol-remove-leftovers-of-cil_mem_error_handler.patch \
+ "
--
2.17.1


Re: Why and when we need to migrate to newer #yocto version? #yocto

Alexander Kanavin
 

On Thu, 4 Jun 2020 at 11:19, Mohamed HAMZAOUI <requinham@...> wrote:
Thanks Alexander,

When you say "The versions of libraries and tools are not independent
from Yocto versions, in fact they are directly defined through oe-core
metadata that is in a specific Yocto version." This not concern Linux
kernel ? because Yocto wiki say "While tooling is provided to use any
Linux kernel you wish, the linux-yocto Linux kernel recipes are tested
with all the emulated targets, the core hardware BSPs, and some vendor
layers."

Yes, the kernel is typically provided by the BSP vendor through the BSP layer, and they define the kernel version in use. The security concerns still apply though: if there is a vulnerability in their kernel, it's much easier to address if the kernel is recent. And newer kernels gain new features too, which might be useful or even required in the project.
 
Then, you cited an important element for maintenance strategy : security issue .
Except the 3.1 LTS, each Yocto version is maintained for 2 releases so
for 1 year. Thus, for security fix, I think the normal way is to track
vulnerabilities and apply patch because migrating to newest Yocto
version every year represents a cost and an enormous effort whereas in
certain cases, all the evolution don't necessarily concern the system
which we uses.
Is my understanding correct?

Tracking vulnerabilities and applying patches is a lot of work, and it becomes harder, the further you are from upstream development. For two reasons:

- security fixes need to be backported. To do that the code should not change too much between the version that has the upstream fix, and version that you need to patch. If you are far behind upstream, chances of that are lower.

- if you can't apply the patch the way it is, and you need to change it, you also need to truly understand what the code is doing and what the fix changes in the code - and for most components that is not the case.

Also, after a Yocto version goes out of support (which happens fairly quickly, previously one year, from now on 6 months for regular releases, and 2 years for LTS ones), you need to do all of the vulnerability tracking yourself; there typically is no shared community effort.

I would recommend the following strategy (and this is what we are using in https://mbition.io/):

- there are two maintained branches, one 'rolling development' branch which tracks master branches of all upstream layers and is periodically pushed forward to bring in the latest upstream changes from all the layers, and another 'stable product' branch which is based on the latest, supported LTS release;

- when a new LTS release happens, 'rolling development' branch is split into two: rolling development continues as it was, and a new 'stable product' branch is created from the same code point. Previous LTS branch can be retired then.

This way, there is never an enormous effort in migrating; instead the migrating effort is spread over the 'rolling development' process, and is continuous in nature.
 

Alex

Mohamed

On Thu, Jun 4, 2020 at 10:38 AM Alexander Kanavin
<alex.kanavin@...> wrote:
>
> The versions of libraries and tools are not independent from Yocto versions, in fact they are directly defined through oe-core metadata that is in a specific Yocto version.
>
> For examples, what version of openssl is in your yocto builds? Is it supported/maintained upstream? What are you going to do if a critical security vulnerability is discovered in that version?
>
> This extends to all of the packages: it makes sense to use the most recent Yocto version for two primary reasons:
>
> - the stack is much less likely to contain security vulnerabilities
> - it is much easier to satisfy project requirements w.r.t. version compatibility, or needed features, if those features are only available in recent versions of the package.
>
> This mailing list gets horror stories all the time from people who are for some reason using some ancient Yocto, then a customer requirement arrives that can only be satisfied through updating to a newer Yocto, or backporting a major component to the old Yocto; both impossible or nearly impossible tasks. You do not want to end up in that situation.
>
> Alex
>
> On Thu, 4 Jun 2020 at 10:18, <requinham@...> wrote:
>>
>> My question is about the #Yocto update and maintenance strategy. I have several projects for different boards and different versions of Yocto (1.7 2.0 2.2) which includes their BSP.
>>
>> As an OS build system, especially GNU/Linux, I don't understand exactly when should we necessarily migrate to a new version?
>>
>> In my understanding, the versions of the kernel, libraries and tools are independent from Yocto version. If you need to migrate to a new version of the Linux kernel, you have to modify/add the right recipe without worrying about the Yocto version.
>>
>> Thus, the maintenance work -security, bugs, optimization- should relate to the recipes and not to Yocto itself.
>>
>> Updating Yocto may have sens for me when we need to use new bitbake feature or new architecture but not to use new version of package. I think we should keep in mind to manage a certain consistency and compatibility between the different versions of the recipes in order for example to use the right version of the openssl library with the right version of Qt or even between the right version of the kernel and drivers, etc.
>> Thanks,
>> Mohamed
>>
>>


Re: Why and when we need to migrate to newer #yocto version? #yocto

Mohamed HAMZAOUI
 

Thanks Alexander,

When you say "The versions of libraries and tools are not independent
from Yocto versions, in fact they are directly defined through oe-core
metadata that is in a specific Yocto version." This not concern Linux
kernel ? because Yocto wiki say "While tooling is provided to use any
Linux kernel you wish, the linux-yocto Linux kernel recipes are tested
with all the emulated targets, the core hardware BSPs, and some vendor
layers."
Then, you cited an important element for maintenance strategy : security issue .
Except the 3.1 LTS, each Yocto version is maintained for 2 releases so
for 1 year. Thus, for security fix, I think the normal way is to track
vulnerabilities and apply patch because migrating to newest Yocto
version every year represents a cost and an enormous effort whereas in
certain cases, all the evolution don't necessarily concern the system
which we uses.
Is my understanding correct?

Mohamed

On Thu, Jun 4, 2020 at 10:38 AM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:

The versions of libraries and tools are not independent from Yocto versions, in fact they are directly defined through oe-core metadata that is in a specific Yocto version.

For examples, what version of openssl is in your yocto builds? Is it supported/maintained upstream? What are you going to do if a critical security vulnerability is discovered in that version?

This extends to all of the packages: it makes sense to use the most recent Yocto version for two primary reasons:

- the stack is much less likely to contain security vulnerabilities
- it is much easier to satisfy project requirements w.r.t. version compatibility, or needed features, if those features are only available in recent versions of the package.

This mailing list gets horror stories all the time from people who are for some reason using some ancient Yocto, then a customer requirement arrives that can only be satisfied through updating to a newer Yocto, or backporting a major component to the old Yocto; both impossible or nearly impossible tasks. You do not want to end up in that situation.

Alex

On Thu, 4 Jun 2020 at 10:18, <requinham@gmail.com> wrote:

My question is about the #Yocto update and maintenance strategy. I have several projects for different boards and different versions of Yocto (1.7 2.0 2.2) which includes their BSP.

As an OS build system, especially GNU/Linux, I don't understand exactly when should we necessarily migrate to a new version?

In my understanding, the versions of the kernel, libraries and tools are independent from Yocto version. If you need to migrate to a new version of the Linux kernel, you have to modify/add the right recipe without worrying about the Yocto version.

Thus, the maintenance work -security, bugs, optimization- should relate to the recipes and not to Yocto itself.

Updating Yocto may have sens for me when we need to use new bitbake feature or new architecture but not to use new version of package. I think we should keep in mind to manage a certain consistency and compatibility between the different versions of the recipes in order for example to use the right version of the openssl library with the right version of Qt or even between the right version of the kernel and drivers, etc.
Thanks,
Mohamed


Re: Why and when we need to migrate to newer #yocto version? #yocto

Alexander Kanavin
 

The versions of libraries and tools are not independent from Yocto versions, in fact they are directly defined through oe-core metadata that is in a specific Yocto version.

For examples, what version of openssl is in your yocto builds? Is it supported/maintained upstream? What are you going to do if a critical security vulnerability is discovered in that version?

This extends to all of the packages: it makes sense to use the most recent Yocto version for two primary reasons:

- the stack is much less likely to contain security vulnerabilities
- it is much easier to satisfy project requirements w.r.t. version compatibility, or needed features, if those features are only available in recent versions of the package.

This mailing list gets horror stories all the time from people who are for some reason using some ancient Yocto, then a customer requirement arrives that can only be satisfied through updating to a newer Yocto, or backporting a major component to the old Yocto; both impossible or nearly impossible tasks. You do not want to end up in that situation.

Alex


On Thu, 4 Jun 2020 at 10:18, <requinham@...> wrote:

My question is about the #Yocto update and maintenance strategy. I have several projects for different boards and different versions of Yocto (1.7 2.0 2.2) which includes their BSP.

As an OS build system, especially GNU/Linux, I don't understand exactly when should we necessarily migrate to a new version?

In my understanding, the versions of the kernel, libraries and tools are independent from Yocto version. If you need to migrate to a new version of the Linux kernel, you have to modify/add the right recipe without worrying about the Yocto version.

Thus, the maintenance work -security, bugs, optimization- should relate to the recipes and not to Yocto itself.

Updating Yocto may have sens for me when we need to use new bitbake feature or new architecture but not to use new version of package. I think we should keep in mind to manage a certain consistency and compatibility between the different versions of the recipes in order for example to use the right version of the openssl library with the right version of Qt or even between the right version of the kernel and drivers, etc.
Thanks,
Mohamed



Why and when we need to migrate to newer #yocto version? #yocto

Mohamed HAMZAOUI
 

My question is about the #Yocto update and maintenance strategy. I have several projects for different boards and different versions of Yocto (1.7 2.0 2.2) which includes their BSP.

As an OS build system, especially GNU/Linux, I don't understand exactly when should we necessarily migrate to a new version?

In my understanding, the versions of the kernel, libraries and tools are independent from Yocto version. If you need to migrate to a new version of the Linux kernel, you have to modify/add the right recipe without worrying about the Yocto version.

Thus, the maintenance work -security, bugs, optimization- should relate to the recipes and not to Yocto itself.

Updating Yocto may have sens for me when we need to use new bitbake feature or new architecture but not to use new version of package. I think we should keep in mind to manage a certain consistency and compatibility between the different versions of the recipes in order for example to use the right version of the openssl library with the right version of Qt or even between the right version of the kernel and drivers, etc.
Thanks,
Mohamed


Re: [PATCH] [meta-swupdate] Fix build error of dependence.

Stefano Babic
 

Hi Zheng,

there is a ML for SWUpdate and meta-swupdate (see CC), we are cross-posting here:

On 04.06.20 14:26, zhengruoqin wrote:
-c -o mongoose/mongoose.o mongoose/mongoose.c
| mongoose/mongoose.c:4496:10: fatal error: openssl/ssl.h: No such file
or directory
Signed-off-by: Zheng Ruoqing <zhengrq.fnst@cn.fujitsu.com>
---
recipes-support/swupdate/swupdate.inc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/recipes-support/swupdate/swupdate.inc b/recipes-support/swupdate/swupdate.inc
index 9ea0a8a..3d9a3fa 100644
--- a/recipes-support/swupdate/swupdate.inc
+++ b/recipes-support/swupdate/swupdate.inc
@@ -123,6 +123,9 @@ python () {
elif 'CONFIG_SSL_IMPL_MBEDTLS=y\n' in features:
depends += ' mbedtls'
+ if 'CONFIG_MONGOOSESSL=y\n' in features:
+ depends += ' openssl'
+
openSSL is not the only supported SSL library, the Webserver runs also with mbedTLS. This patch forces to use openSSL and conflicts in case mbedTLS is used as signing and crypto library.

if 'CONFIG_JSON=y\n' in features:
depends += ' json-c'
Best regards,
Stefano Babic


[PATCH] [meta-swupdate] Fix build error of dependence.

zhengruoqin
 

-c -o mongoose/mongoose.o mongoose/mongoose.c
| mongoose/mongoose.c:4496:10: fatal error: openssl/ssl.h: No such file
or directory

Signed-off-by: Zheng Ruoqing <zhengrq.fnst@cn.fujitsu.com>
---
recipes-support/swupdate/swupdate.inc | 3 +++
1 file changed, 3 insertions(+)

diff --git a/recipes-support/swupdate/swupdate.inc b/recipes-support/swupdate/swupdate.inc
index 9ea0a8a..3d9a3fa 100644
--- a/recipes-support/swupdate/swupdate.inc
+++ b/recipes-support/swupdate/swupdate.inc
@@ -123,6 +123,9 @@ python () {
elif 'CONFIG_SSL_IMPL_MBEDTLS=y\n' in features:
depends += ' mbedtls'

+ if 'CONFIG_MONGOOSESSL=y\n' in features:
+ depends += ' openssl'
+
if 'CONFIG_JSON=y\n' in features:
depends += ' json-c'

--
2.17.1


Re: Why does setting PATCHTOOL="git" result in do_patch trying to look at git hooks in the host repo?

Sean McKay
 

I retract my question and apologize for being an idiot…

Apparently somewhere along the line while I wasn’t paying attention, the entirety of that upstream git repo got pulled into our local codebase, so I was trying to use git patching on a directory fetched with file://

Sigh... time to go fix it. At least it makes sense.

 

Cheers!

-Sean

 

From: yocto@... <yocto@...> On Behalf Of Sean McKay
Sent: Tuesday, June 2, 2020 7:41 PM
To: yocto@...
Subject: [yocto] Why does setting PATCHTOOL="git" result in do_patch trying to look at git hooks in the host repo?

 

Hi all,

 

I have a component in our build that’s pulling from an upstream git server, so I decided to set the PATCHTOOL=”git” so that it’s easier to determine in the local repository what patches have been applied (since using the git PATCHTOOL results in full commits, whereas quilt just makes a mess and everything goes into the child git repo as a giant unstaged change).

 

However, in testing, I’m hitting this failure if I’m building in a git worktree:

*** 0505:        os.mkdir(hooks_dir)

     0506:        commithook = os.path.join(hooks_dir, 'commit-msg')

     0507:        applyhook = os.path.join(hooks_dir, 'applypatch-msg')

     0508:        with open(commithook, 'w') as f:

     0509:            # NOTE: the formatting here is significant; if you change it you'll also need to

Exception: NotADirectoryError: [Errno 20] Not a directory: '/ws/mckays/zeus-test/.git/hooks'

 

Now, to be fair, it’s quite correct – that isn’t a directory, since that’s not how git worktrees operate.

I can probably come up with a patch to submit upstream to correct this behavior, but I can’t fathom why the patcher should logically be trying to do anything with the parent git repo for any reason. And I can solve this for git worktrees, but what if someone just has a tarball and isn’t trying to build inside git at all – wouldn’t they hit the same failure?

 

I’d appreciate any clarity you can provide. Thanks!!!

 

-Sean

 

 

Full stack trace:

The stack trace of python calls that resulted in this exception/failure was:

File: 'exec_python_func() autogenerated', lineno: 2, function: <module>

    0001:

*** 0002:patch_do_patch(d)

     0003:

File: '/ws/mckays/zeus-test/yocto/poky/meta/classes/patch.bbclass', lineno: 145, function: patch_do_patch

     0141:        except Exception as exc:

     0142:            bb.utils.remove(process_tmpdir, True)

     0143:            bb.fatal(str(exc))

     0144:        try:

*** 0145:            resolver.Resolve()

     0146:        except bb.BBHandledException as e:

     0147:            bb.utils.remove(process_tmpdir, True)

     0148:            bb.fatal(str(e))

     0149:

File: '/ws/mckays/zeus-test/yocto/poky/meta/lib/oe/patch.py', lineno: 716, function: Resolve

     0712:    def Resolve(self):

     0713:        olddir = os.path.abspath(os.curdir)

     0714:        os.chdir(self.patchset.dir)

     0715:        try:

*** 0716:            self.patchset.Push()

     0717:        except Exception:

     0718:            import sys

     0719:            os.chdir(olddir)

     0720:            raise

File: '/ws/mckays/zeus-test/yocto/poky/meta/lib/oe/patch.py', lineno: 267, function: Push

     0263:            else:

     0264:                next = 0

     0265:

     0266:            bb.note("applying patch %s" % self.patches[next])

*** 0267:            ret = self._applypatch(self.patches[next], force)

     0268:

     0269:            self._current = next

     0270:            return ret

     0271:

File: '/ws/mckays/zeus-test/yocto/poky/meta/lib/oe/patch.py', lineno: 505, function: _applypatch

     0501:        if os.path.lexists(hooks_dir_backup):

     0502:            raise Exception("Git hooks backup directory already exists: %s" % hooks_dir_backup)

     0503:        if os.path.lexists(hooks_dir):

     0504:            shutil.move(hooks_dir, hooks_dir_backup)

*** 0505:        os.mkdir(hooks_dir)

     0506:        commithook = os.path.join(hooks_dir, 'commit-msg')

     0507:        applyhook = os.path.join(hooks_dir, 'applypatch-msg')

     0508:        with open(commithook, 'w') as f:

     0509:            # NOTE: the formatting here is significant; if you change it you'll also need to

Exception: NotADirectoryError: [Errno 20] Not a directory: '/ws/mckays/zeus-test/.git/hooks'

 


Re: Eclipse GDB setup issues; can't determine cause for SIGSEGV

Khem Raj
 

On Wed, Jun 3, 2020 at 9:41 AM Bryan Evenson <bevenson@melinkcorp.com> wrote:

Khem,

-----Original Message-----
From: Khem Raj <raj.khem@gmail.com>
Sent: Tuesday, June 2, 2020 2:20 PM
To: Bryan Evenson <bevenson@melinkcorp.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] Eclipse GDB setup issues; can't determine cause for
SIGSEGV

On Tue, Jun 2, 2020 at 6:52 AM Bryan Evenson <bevenson@melinkcorp.com>
wrote:

All,


-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On
Behalf Of Bryan Evenson via lists.yoctoproject.org
Sent: Monday, June 1, 2020 4:46 PM
To: Bryan Evenson <bevenson@melinkcorp.com>;
yocto@lists.yoctoproject.org
Subject: Re: [yocto] Eclipse GDB setup issues; can't determine cause
for SIGSEGV

All,

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org>
On Behalf Of Bryan Evenson via lists.yoctoproject.org
Sent: Monday, June 1, 2020 11:16 AM
To: yocto@lists.yoctoproject.org
Subject: [yocto] Eclipse GDB setup issues; can't determine cause
for
SIGSEGV

All,

I have a AT91SAM9G25 system that has been idle for a couple years
(running
morty, yocto version 2.2.1) and I am working on updating to the
latest
Yocto
production branch. Before I get there, I'm trying to confirm the
old setup and I'm having problems with remote debugging. I know
there have been changes since yocto version 2.7 for debugging
support, so I want to make sure I can get the old setup to work
first prior to changing everything. I'm looking for assistance in tracking
down my debug issues.

My stable production image is based off of core-image-minimal,
with a few additional packages for our proprietary applications
(proprietary
applications
are written in C). I also have a development image, based off of
our production image, with the following additions:

IMAGE_FEATURES += "package-management dev-pkgs eclipse-debug
allow-
empty-password empty-root-password"

IMAGE_INSTALL += " \
#same additional packages as production image \
#"-dbg" version of proprietary applications \
gdbserver \
"
# Strip python from the image to reduce the image size
PACKAGE_EXCLUDE = "python"

I have the Eclipse Yocto plugin installed and it is setup to use
the SDK that I have built based on the development image. I've
confirmed that I can start
a
debug session on one of our proprietary applications. I can set
breakpoints and run the debugger. However, the debugger always
stops at the first call to uuid_compare with a SIGSEGV. The last
line in the call stack states "<symbol is not available>
0x00000000". From my understanding, the stack pointer is getting
set to NULL when uuid_compare is getting called. If I stop the
debugger and just run the application on the hardware, the
application runs without errors. I have confirmed with syslog
messages that I do not have the same NULL stack pointer issue when
I run the application outside
of
the debugger.

Any suggestions on where to start looking? I don't see any
obvious
possible
causes and I don't know where to start looking for the problem.
On a whim, I changed in my code:
if(uuid_compare(uuid1, uuid2) == 0)

To:
If(memcmp(uuid1, uuid2, 16) == 0)

After this change the problematic line of code worked just fine.
The debugger worked fine until I got to the next spot in my code
that called uuid_compare. At the next call to uuid_compare I got
the same SIGSEGV error I had before. Something is clearly a problem
with calling uuid_compare.
However, I'm using several other functions from the uuid library
(uuid_is_null, uuid_parse, uuid_unparse for a few) and none of them
are causing problems. I don't think it's a problem with the input
parameters because I'm passing the same UUIDs to memcomp as I did to
uuid_compare.
Has anyone ever seen only one function from a library cause problems
like this?
I don't know if this is related, but I noticed that the debugger cannot step
into any library functions. For example, I tried stepping into strncpy, and the
debugger stepped over the function call. I switched to assembly instruction
stepping mode, then when I stepped into strncpy I received the message
"No source available for strncpy@plt". I continued single stepping and was
able to step through all the assembly code for strncpy. I then instruction
single stepped into uuid_compare, and I was able to single step without issue
until I got to the following instruction:
bx r12
When this instruction is called, r12 is 0. I'm a little confused why this library
function call is failing in this manner (when all the input parameters to
uuid_compare are valid), and I'm not sure why I can't source step through
any library functions. If anyone has any suggestions on either issue, please
let me know.

It seems you are using thumb1 ISA, and usually, there is some sort of veneer
code to switch from arm mode to thumb mode which might employ this kind
of indirect jumps perhaps in e2fsprogs recipe, you can add
INHIBIT_PACKAGE_STRIP = "1" temporarily and load the image, perhaps that
can give you better debugging experience, but it seems there is a code-gen
bug as it seems.
Thanks for the suggestions. I tried these suggestions and it didn't help. I replaced all the uuid_compare calls in my code and I was able to do some debugging. But then I started having other odd problems with SIGABRT and SIGSEGV errors at points that normally work.

I then merged in some code from another developer which is using an older SDK. I wasn't able to build any more and determined the makefiles and configure needed updated (autotools based program). A simple autoreconf didn't fix it; I had to invoke aclocal, autoconf, automake and then autoreconf. After all these changes, I can now debug my application without it crashing. The uuid_compare calls are working just fine and I've been able to run the debugger and set breakpoints in many parts of my code. I don't fully understand why it was the issue, but it appears I needed to do a more in-depth autotools reconfiguration for debugging to work with my copy of the SDK.
what code did you merge and was it into layers? or your app.
autoreconf helping would
mean that its some pre-generated header etc. I am not sure what was
causing it and not sure
what fixed it

Thanks,
Bryan


Thanks,
Bryan


Thanks,
Bryan

3541 - 3560 of 53122