1. yocto@lists.yoctoproject.org
   Date   
Re: wvdial

Maciej Pijanowski
 


On 17.09.2020 13:35, Maciej Pijanowski wrote:


On 17.09.2020 13:25, Zoltan Kerenyi Nagy wrote:
now there is only one issue has left:

ERROR: ExpansionError during parsing /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvdial/wvdial_1.61.bb                                                                                       | ETA:  0:00:00
Traceback (most recent call last):
bb.data_smart.ExpansionError: Failure expanding variable do_fetch[file-checksums], expression was ${@bb.fetch.get_checksum_file_list(d)}  ${@get_lic_checksum_file_list(d)} which triggered exception NoMethodError: Could not find a fetcher which supports the URL: 'files://typo_pon.wvdial.1.patch'


I'm sorry, but you I think you really do need a pair of glasses ;)
It's supposed to be file:// not file:// in the URL.

It's supposed to be file:// not files:// in the URL.



This is the bb recipe:

HOMEPAGE = "http://www.alumnit.ca/wiki/?WvDial"
DESCRIPTION = "WvDial is a program that makes it easy to connect your Linux workstation to the Internet."

LICENSE = "LGPLv2"
LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=55ca817ccb7d5b5b66355690e9abc605"

inherit pkgconfig

DEPENDS = "wvstreams"
RDEPENDS_${PN} = "ppp"

SRC_URI = "http://${BPN}.googlecode.com/files/${BP}.tar.bz2 \
           files://typo_pon.wvdial.1.patch \
          "

SRC_URI[md5sum] = "d81642557d175d8e0818f4721c27dfcf"
SRC_URI[sha256sum] = "a2ce46c8c36870a0f2fa92ea64566df7251fb2d8d5aa2f6ef2b08d188287352e"

EXTRA_OEMAKE = ""
export WVLINK="${LD}"

PARALLEL_MAKE = ""

BUILD_CPPFLAGS += "-I${STAGING_INCDIR}/wvstreams"

do_configure() {
    sed -i 's/LDFLAGS+=-luniconf/LIBS+=-luniconf/' ${S}/Makefile
}

do_install() {
    oe_runmake prefix=${D}/usr PPPDIR=${D}/etc/ppp/peers install
}
# http://errors.yoctoproject.org/Errors/Details/186959/
EXCLUDE_FROM_WORLD_libc-musl = "1"

Ive  re-generated the md5 and sha256 hashes, and all the warnings have disapeared.

Here is the patch:
if I modify teh 3rd line to "Index: wvdial-1.61/files/pon.wvdial.1" - the error is the same

Remove warnings found by lintian
Last-Update: 2011-01-09
Index: wvdial-1.61/pon.wvdial.1
===================================================================
--- wvdial-1.61.orig/pon.wvdial.1	2011-01-09 21:33:03.000000000 +0300
+++ wvdial-1.61/pon.wvdial.1	2011-01-09 21:33:15.000000000 +0300
@@ -8,13 +8,11 @@
 .SH DESCRIPTION
 .B pon.wvdial
 .br
-.TR
 .B poff.wvdial
 .br
 .RS
 Replacement scripts for pon and poff.
 .RE
-\."
 .SH SEE ALSO
 .BR wvdial (1),
 .BR pon (1),





-- 
Maciej Pijanowski
Embedded Systems Engineer
GPG: 9963C36AAC3B2B46
https://3mdeb.com | @3mdeb_com
-- 
Maciej Pijanowski
Embedded Systems Engineer
GPG: 9963C36AAC3B2B46
https://3mdeb.com | @3mdeb_com
Re: wvdial

Maciej Pijanowski
 


On 17.09.2020 13:25, Zoltan Kerenyi Nagy wrote:
now there is only one issue has left:

ERROR: ExpansionError during parsing /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvdial/wvdial_1.61.bb                                                                                       | ETA:  0:00:00
Traceback (most recent call last):
bb.data_smart.ExpansionError: Failure expanding variable do_fetch[file-checksums], expression was ${@bb.fetch.get_checksum_file_list(d)}  ${@get_lic_checksum_file_list(d)} which triggered exception NoMethodError: Could not find a fetcher which supports the URL: 'files://typo_pon.wvdial.1.patch'


I'm sorry, but you I think you really do need a pair of glasses ;)
It's supposed to be file:// not file:// in the URL.


This is the bb recipe:

HOMEPAGE = "http://www.alumnit.ca/wiki/?WvDial"
DESCRIPTION = "WvDial is a program that makes it easy to connect your Linux workstation to the Internet."

LICENSE = "LGPLv2"
LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=55ca817ccb7d5b5b66355690e9abc605"

inherit pkgconfig

DEPENDS = "wvstreams"
RDEPENDS_${PN} = "ppp"

SRC_URI = "http://${BPN}.googlecode.com/files/${BP}.tar.bz2 \
           files://typo_pon.wvdial.1.patch \
          "

SRC_URI[md5sum] = "d81642557d175d8e0818f4721c27dfcf"
SRC_URI[sha256sum] = "a2ce46c8c36870a0f2fa92ea64566df7251fb2d8d5aa2f6ef2b08d188287352e"

EXTRA_OEMAKE = ""
export WVLINK="${LD}"

PARALLEL_MAKE = ""

BUILD_CPPFLAGS += "-I${STAGING_INCDIR}/wvstreams"

do_configure() {
    sed -i 's/LDFLAGS+=-luniconf/LIBS+=-luniconf/' ${S}/Makefile
}

do_install() {
    oe_runmake prefix=${D}/usr PPPDIR=${D}/etc/ppp/peers install
}
# http://errors.yoctoproject.org/Errors/Details/186959/
EXCLUDE_FROM_WORLD_libc-musl = "1"

Ive  re-generated the md5 and sha256 hashes, and all the warnings have disapeared.

Here is the patch:
if I modify teh 3rd line to "Index: wvdial-1.61/files/pon.wvdial.1" - the error is the same

Remove warnings found by lintian
Last-Update: 2011-01-09
Index: wvdial-1.61/pon.wvdial.1
===================================================================
--- wvdial-1.61.orig/pon.wvdial.1	2011-01-09 21:33:03.000000000 +0300
+++ wvdial-1.61/pon.wvdial.1	2011-01-09 21:33:15.000000000 +0300
@@ -8,13 +8,11 @@
 .SH DESCRIPTION
 .B pon.wvdial
 .br
-.TR
 .B poff.wvdial
 .br
 .RS
 Replacement scripts for pon and poff.
 .RE
-\."
 .SH SEE ALSO
 .BR wvdial (1),
 .BR pon (1),






-- 
Maciej Pijanowski
Embedded Systems Engineer
GPG: 9963C36AAC3B2B46
https://3mdeb.com | @3mdeb_com
wvdial

Zoltan Kerenyi Nagy
 

now there is only one issue has left:

ERROR: ExpansionError during parsing /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvdial/wvdial_1.61.bb                                                                                       | ETA:  0:00:00
Traceback (most recent call last):
bb.data_smart.ExpansionError: Failure expanding variable do_fetch[file-checksums], expression was ${@bb.fetch.get_checksum_file_list(d)}  ${@get_lic_checksum_file_list(d)} which triggered exception NoMethodError: Could not find a fetcher which supports the URL: 'files://typo_pon.wvdial.1.patch'

This is the bb recipe:

HOMEPAGE = "http://www.alumnit.ca/wiki/?WvDial"
DESCRIPTION = "WvDial is a program that makes it easy to connect your Linux workstation to the Internet."

LICENSE = "LGPLv2"
LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=55ca817ccb7d5b5b66355690e9abc605"

inherit pkgconfig

DEPENDS = "wvstreams"
RDEPENDS_${PN} = "ppp"

SRC_URI = "http://${BPN}.googlecode.com/files/${BP}.tar.bz2 \
           files://typo_pon.wvdial.1.patch \
          "

SRC_URI[md5sum] = "d81642557d175d8e0818f4721c27dfcf"
SRC_URI[sha256sum] = "a2ce46c8c36870a0f2fa92ea64566df7251fb2d8d5aa2f6ef2b08d188287352e"

EXTRA_OEMAKE = ""
export WVLINK="${LD}"

PARALLEL_MAKE = ""

BUILD_CPPFLAGS += "-I${STAGING_INCDIR}/wvstreams"

do_configure() {
    sed -i 's/LDFLAGS+=-luniconf/LIBS+=-luniconf/' ${S}/Makefile
}

do_install() {
    oe_runmake prefix=${D}/usr PPPDIR=${D}/etc/ppp/peers install
}
# http://errors.yoctoproject.org/Errors/Details/186959/
EXCLUDE_FROM_WORLD_libc-musl = "1"

Ive  re-generated the md5 and sha256 hashes, and all the warnings have disapeared.

Here is the patch:
if I modify teh 3rd line to "Index: wvdial-1.61/files/pon.wvdial.1" - the error is the same

Remove warnings found by lintian
Last-Update: 2011-01-09
Index: wvdial-1.61/pon.wvdial.1
===================================================================
--- wvdial-1.61.orig/pon.wvdial.1	2011-01-09 21:33:03.000000000 +0300
+++ wvdial-1.61/pon.wvdial.1	2011-01-09 21:33:15.000000000 +0300
@@ -8,13 +8,11 @@
 .SH DESCRIPTION
 .B pon.wvdial
 .br
-.TR
 .B poff.wvdial
 .br
 .RS
 Replacement scripts for pon and poff.
 .RE
-\."
 .SH SEE ALSO
 .BR wvdial (1),
 .BR pon (1),

[PATCH yocto-autobuilder-helper] auh: correct the SMTP server in config file

Alexander Kanavin
 

Michael Halstead has confirmed this.

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
scripts/auh-config/upgrade-helper.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/auh-config/upgrade-helper.conf b/scripts/auh-config/upgrade-helper.conf
index b012600..5284b4a 100644
--- a/scripts/auh-config/upgrade-helper.conf
+++ b/scripts/auh-config/upgrade-helper.conf
@@ -9,7 +9,7 @@ blacklist=linux-libc-headers linux-yocto alsa-utils-scripts build-appliance-imag
# only recipes belonging to maintainers in whitelist will be attempted
#maintainers_whitelist=anibal.limon@linux.intel.com
# SMTP server
-smtp=smtp1.yoctoproject.org:25
+smtp=mail.yoctoproject.org:25
# from whom should the mails arrive
from=auh@auh.yoctoproject.org
# who should get the status mail with statistics, at the end
--
2.28.0
Re: RFC: Changes to meta-kernel layer

Jack Mitchell
 

On 17/09/2020 10:40, Bas Mevissen wrote:
On 2020-09-17 10:43, Paul Barker wrote:

Hi folks,

After a bit of a break I'm looking again at the meta-kernel layer and
I've got some changes planned. I'd like to get some feedback on these
from anyone who has looked at or used the meta-kernel layer.

1) Change the name to meta-vanilla-kernel. This reflects the focus on
providing a fast moving layer for vanilla kernel recipes, covering
only what is available on kernel.org. Other common kernel recipes
(e.g. Linaro or Android common kernels) will no longer be considered
for acceptance into this layer. This clear focus should hopefully
reduce some of the confusion about the goals of this layer.
I would suggest calling it something like meta-kernel.org then. Naming
something "vanilla" might cause confusion as well.
I wasn't going to be blamed for the bike shedding of this but as we've
gotten started I'll stick my oar in. My suggestion would be
meta-mainline-kernel, meta-linux-kernel or potentially
meta-upstream-kernel but I'm not so keen on that. Vanilla is a confusing
term for people not in the game and you know at some point there will be
a "vanilla-pi" or "vanilla" board where you're going to hit confusion.

As an aside I saw no issues with meta-kernel as it's _the_ Linux kernel
from _the_ Linux kernel git repositories. Confusion due to doublespeak
from downstream kernel vendors should be corrected and not adhered to.


2) The dunfell branch will no longer get new non-LTS kernel recipes.
Providing non-LTS recipes on a stable branch has led to people
depending on kernels which are now out of their support period - I'd
like to drop the recipes for the 5.3.y and 5.6.y kernels but users are
depending on them so I'll have to keep them. To avoid this
proliferating, only LTS kernels and the bleeding edge mainline recipe
will be updated on the stable branch from now >>
3) Aggressively drop end-of-life kernels on the master branch.

4) Drop all non-LTS kernel recipes in the gatesgarth branch when it is
created.
I think these are fair, I can't speak for how other people are using the
layer but I would imagine as with most embedded boards, they're using
the tooling rather than the plain upstream recipes and the real value is
in catching problems with -next kernel compilation early and the
fixes/features pushed back to kernel.bbclass.

5) Document the test coverage for meta-kernel. We don't test perf,
lttng or any out-of-tree modules. This layer isn't meant to replace
the linux-yocto recipes, the goals are different. If you're releasing
products based on meta-kernel you obviously need to do your own
testing on the components you're actually using.
I wouldn't be expecting anything more than basic build and boot on qemu
to be fair. Again, IMO the value of this is in the toolchain test and
tooling.


6) Document the policy for kernel patches. Patches for the kernel will
only be carried in this layer as a last resort. Kernel patches should
be submitted upstream and go through the usual process for inclusion
in the stable kernel releases.
Compilation patches only I would say.


7) Disable GitLab CI for this layer. It's costing me about £70 per
month to run CI for this layer and I need to eliminate that expense.
If anyone can sponsor this or host the CI service that would be welcome.

8) Add Jon Mason and Ross Burton (both at ARM) as backup maintainers
to reduce the bus factor for the layer. I'll continue to be the
primary maintainer for this layer but this will give some coverage if
I'm unable to continue working on it.

Thanks,

--

Paul Barker
Konsulko Group
Cheers,
Jack.
split rootfs into partitions for rauc

Daniel Ammann
 

Hi

Is it possible to split a rootfs image into two images for two partitions?
Let's say I have a rootfs, but I want to split out /usr/local/applicationx into
a separate image so that I can have it on a different partition. The goal is to
have two ext4 images, one with everything except /usr/local/applicationx and
one with just /usr/local/applicationx.

Thanks, Daniel

--
bytes at work
Technoparkstrasse 7
CH-8406 Winterthur
Switzerland

phone: +41 52 550 50 67
Re: RFC: Changes to meta-kernel layer

Bas Mevissen
 

On 2020-09-17 10:43, Paul Barker wrote:

Hi folks,
After a bit of a break I'm looking again at the meta-kernel layer and I've got some changes planned. I'd like to get some feedback on these from anyone who has looked at or used the meta-kernel layer.
1) Change the name to meta-vanilla-kernel. This reflects the focus on providing a fast moving layer for vanilla kernel recipes, covering only what is available on kernel.org. Other common kernel recipes (e.g. Linaro or Android common kernels) will no longer be considered for acceptance into this layer. This clear focus should hopefully reduce some of the confusion about the goals of this layer.
I would suggest calling it something like meta-kernel.org then. Naming something "vanilla" might cause confusion as well.

2) The dunfell branch will no longer get new non-LTS kernel recipes. Providing non-LTS recipes on a stable branch has led to people depending on kernels which are now out of their support period - I'd like to drop the recipes for the 5.3.y and 5.6.y kernels but users are depending on them so I'll have to keep them. To avoid this proliferating, only LTS kernels and the bleeding edge mainline recipe will be updated on the stable branch from now on.
I would recommend maintaining a "kernel-stable" moving target recipe that tracks the latest stable version of kernel.org. This is of use for people needing a very recent kernel, while needing a stable environment for the rest of the system (so where master is no option).

3) Aggressively drop end-of-life kernels on the master branch.
Always good to keep the amount of kernels at an absolut minimum to limit the amount of testing and maintenance.

4) Drop all non-LTS kernel recipes in the gatesgarth branch when it is created.
See 2); additionally the next-to-be-lts might be considered

5) Document the test coverage for meta-kernel. We don't test perf, lttng or any out-of-tree modules. This layer isn't meant to replace the linux-yocto recipes, the goals are different. If you're releasing products based on meta-kernel you obviously need to do your own testing on the components you're actually using.
6) Document the policy for kernel patches. Patches for the kernel will only be carried in this layer as a last resort. Kernel patches should be submitted upstream and go through the usual process for inclusion in the stable kernel releases.
7) Disable GitLab CI for this layer. It's costing me about £70 per month to run CI for this layer and I need to eliminate that expense. If anyone can sponsor this or host the CI service that would be welcome.
8) Add Jon Mason and Ross Burton (both at ARM) as backup maintainers to reduce the bus factor for the layer. I'll continue to be the primary maintainer for this layer but this will give some coverage if I'm unable to continue working on it.
And spreading the workload of course!

Thanks,
--
Paul Barker
Konsulko Group
Regards,

Bas.
RFC: Changes to meta-kernel layer

Paul Barker
 

Hi folks,

After a bit of a break I'm looking again at the meta-kernel layer and I've got some changes planned. I'd like to get some feedback on these from anyone who has looked at or used the meta-kernel layer.

1) Change the name to meta-vanilla-kernel. This reflects the focus on providing a fast moving layer for vanilla kernel recipes, covering only what is available on kernel.org. Other common kernel recipes (e.g. Linaro or Android common kernels) will no longer be considered for acceptance into this layer. This clear focus should hopefully reduce some of the confusion about the goals of this layer.

2) The dunfell branch will no longer get new non-LTS kernel recipes. Providing non-LTS recipes on a stable branch has led to people depending on kernels which are now out of their support period - I'd like to drop the recipes for the 5.3.y and 5.6.y kernels but users are depending on them so I'll have to keep them. To avoid this proliferating, only LTS kernels and the bleeding edge mainline recipe will be updated on the stable branch from now on.

3) Aggressively drop end-of-life kernels on the master branch.

4) Drop all non-LTS kernel recipes in the gatesgarth branch when it is created.

5) Document the test coverage for meta-kernel. We don't test perf, lttng or any out-of-tree modules. This layer isn't meant to replace the linux-yocto recipes, the goals are different. If you're releasing products based on meta-kernel you obviously need to do your own testing on the components you're actually using.

6) Document the policy for kernel patches. Patches for the kernel will only be carried in this layer as a last resort. Kernel patches should be submitted upstream and go through the usual process for inclusion in the stable kernel releases.

7) Disable GitLab CI for this layer. It's costing me about £70 per month to run CI for this layer and I need to eliminate that expense. If anyone can sponsor this or host the CI service that would be welcome.

8) Add Jon Mason and Ross Burton (both at ARM) as backup maintainers to reduce the bus factor for the layer. I'll continue to be the primary maintainer for this layer but this will give some coverage if I'm unable to continue working on it.

Thanks,

--
Paul Barker
Konsulko Group
Re: wvdial

Bas Mevissen
 

On 2020-09-17 10:02, Zoltan Kerenyi Nagy wrote:

Hi,
Here is the error now, all the files are there, it says that 04_signed_request.diff is not there:
WARNING: wvstreams-4.6.1-r0 do_fetch: Failed to fetch URL file://04_signed_request.diff, attempting MIRRORS if available
ERROR: wvstreams-4.6.1-r0 do_fetch: Fetcher failure: Unable to find file file://04_signed_request.diff anywhere. The paths that were searched were:
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/nodistro
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/nodistro
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/nodistro
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/barix-ipam400
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/barix-ipam400
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/barix-ipam400
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/sun8i
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/sun8i
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/sun8i
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/armv7ve
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/armv7ve
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/armv7ve
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/arm
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/arm
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/arm
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/
/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/
/home/kerenyiz/oe-core/build/downloads
ERROR: wvstreams-4.6.1-r0 do_fetch: Fetcher failure for URL: 'file://04_signed_request.diff'. Unable to fetch URL from any source.
It is the first local file on the list, so this hints that it is probably a file location issue and not a file naming one.

ERROR: wvstreams-4.6.1-r0 do_fetch: Function failed: base_do_fetch
ERROR: Logfile of failure stored in: /home/kerenyiz/oe-core/build/tmp-glibc/work/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/wvstreams/4.6.1-r0/temp/log.do_fetch.8864
ERROR: Task (/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams_4.6.1.bb:do_fetch) failed with exit code '1'
Here i sthe folder structure:
├── file
Here is your problem: this directory should be named "wvstreams"

│ ├── 0001-build-fix-parallel-make.patch
│ ├── 0001-Check-for-limits.h-during-configure.patch
│ ├── 0001-Forward-port-to-OpenSSL-1.1.x.patch
│ ├── 0002-wvrules.mk-Use-_DEFAULT_SOURCE.patch
│ ├── 0002-wvtask-Dont-use-ucontext-on-non-glibc-systems.patch
│ ├── 0003-wvtask-Check-for-HAVE_LIBC_STACK_END-only-on-glibc-s.patch
│ ├── 0004-wvcrash-Replace-use-of-basename-API.patch
│ ├── 0005-check-for-libexecinfo-during-configure.patch
│ ├── 04_signed_request.diff
│ ├── 05_gcc.diff
│ ├── 06_gcc-4.7.diff
│ ├── 07_buildflags.diff
│ ├── argp.patch
│ ├── gcc-6.patch
│ └── openssl-buildfix.patch
└── wvstreams_4.6.1.bb
And this is the recipie file:
HOMEPAGE = "http://alumnit.ca/wiki/index.php?page=WvStreams";
SUMMARY = "WvStreams is a network programming library in C++"
LICENSE = "LGPLv2"
LIC_FILES_CHKSUM = "file://LICENSE;md5=55ca817ccb7d5b5b66355690e9abc605"
DEPENDS = "zlib openssl (>= 0.9.8) dbus readline"
DEPENDS_append_libc-musl = " argp-standalone libexecinfo"
SRC_URI = "http://${BPN}.googlecode.com/files/${BP}.tar.gz \
file://04_signed_request.diff \
file://05_gcc.diff \
file://06_gcc-4.7.diff \
file://07_buildflags.diff \
file://gcc-6.patch \
file://argp.patch \
file://0001-Check-for-limits.h-during-configure.patch \
file://0002-wvtask-Dont-use-ucontext-on-non-glibc-systems.patch \
file://0003-wvtask-Check-for-HAVE_LIBC_STACK_END-only-on-glibc-s.patch \
file://0004-wvcrash-Replace-use-of-basename-API.patch \
file://0005-check-for-libexecinfo-during-configure.patch \
file://0001-build-fix-parallel-make.patch \
file://0002-wvrules.mk-Use-_DEFAULT_SOURCE.patch \
file://openssl-buildfix.patch \
file://0001-Forward-port-to-OpenSSL-1.1.x.patch \
"
SRC_URI[md5sum] = "2760dac31a43d452a19a3147bfde571c"
SRC_URI[sha256sum] = "8403f5fbf83aa9ac0c6ce15d97fd85607488152aa84e007b7d0621b8ebc07633"
inherit autotools-brokensep pkgconfig
TARGET_CFLAGS_append = " -fno-tree-dce -fno-optimize-sibling-calls"
LDFLAGS_append = " -Wl,-rpath-link,${CROSS_DIR}/${TARGET_SYS}/lib"
EXTRA_OECONF = " --without-tcl --without-qt --without-pam --without-valgrind"
PACKAGES_prepend = "libuniconf "
PACKAGES_prepend = "uniconfd "
PACKAGES_prepend = "libwvstreams-base "
PACKAGES_prepend = "libwvstreams-extras "
PACKAGES_prepend = "${PN}-valgrind "
RPROVIDES_${PN}-dbg += "libuniconf-dbg uniconfd-dbg libwvstreams-base-dbg libwvstreams-extras-dbg"
FILES_libuniconf = "${libdir}/libuniconf.so.*"
FILES_uniconfd = "${sbindir}/uniconfd ${sysconfdir}/uniconf.conf ${localstatedir}/uniconf"
FILES_libwvstreams-base = "${libdir}/libwvutils.so.*"
FILES_libwvstreams-extras = "${libdir}/libwvbase.so.* ${libdir}/libwvstreams.so.*"
FILES_${PN}-valgrind = "${libdir}/valgrind/wvstreams.supp"
RDEPENDS_${PN} += "perl"
Re: wvdial

Quentin Schulz
 

Hi

On Thu, Sep 17, 2020 at 10:02:47AM +0200, Zoltan Kerenyi Nagy wrote:
[...]
file://04_signed_request.diff anywhere. The paths that were searched were:

/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/nodistro

/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/nodistro

/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/nodistro

/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/barix-ipam400

/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/barix-ipam400

/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/barix-ipam400

/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/sun8i

/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/sun8i

/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/sun8i

/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/armv7ve

/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/armv7ve

/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/armv7ve

/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/arm

/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/arm

/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/arm

/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/

/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/

/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/
/home/kerenyiz/oe-core/build/downloadsERROR: wvstreams-4.6.1-r0 do_fetch:
Fetcher failure for URL: 'file://04_signed_request.diff'. Unable to fetch
URL from any source.ERROR: wvstreams-4.6.1-r0 do_fetch: Function failed:
base_do_fetchERROR: Logfile of failure stored in:
/home/kerenyiz/oe-core/build/tmp-glibc/work/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/wvstreams/4.6.1-r0/temp/log.do_fetch.8864ERROR:
Task
(/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams_4.6.1.bb:do_fetch)
failed with exit code '1'*

*Here i sthe folder structure:*

├── file
^^^

If you read carefully the paths that were searched you'll see that this
directory is missing a trailing s :) It should be `files` and not `file`.

Cheers,
Quentin
Re: wvdial

Maciej Pijanowski
 


On 17.09.2020 10:02, Zoltan Kerenyi Nagy wrote:
Hi,

Here is the error now, all the files are there, it says that 04_signed_request.diff is not there:

WARNING: wvstreams-4.6.1-r0 do_fetch: Failed to fetch URL file://04_signed_request.diff, attempting MIRRORS if available
ERROR: wvstreams-4.6.1-r0 do_fetch: Fetcher failure: Unable to find file file://04_signed_request.diff anywhere. The paths that were searched were:
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/nodistro
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/nodistro
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/nodistro
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/barix-ipam400
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/barix-ipam400
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/barix-ipam400
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/sun8i
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/sun8i
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/sun8i
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/armv7ve
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/armv7ve
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/armv7ve
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/arm
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/arm
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/arm
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/
    /home/kerenyiz/oe-core/build/downloads
ERROR: wvstreams-4.6.1-r0 do_fetch: Fetcher failure for URL: 'file://04_signed_request.diff'. Unable to fetch URL from any source.
ERROR: wvstreams-4.6.1-r0 do_fetch: Function failed: base_do_fetch
ERROR: Logfile of failure stored in: /home/kerenyiz/oe-core/build/tmp-glibc/work/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/wvstreams/4.6.1-r0/temp/log.do_fetch.8864
ERROR: Task (/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams_4.6.1.bb:do_fetch) failed with exit code '1'

Here i sthe folder structure:

├── file
Well, as you can see this directory is not one of the search paths in the log above. Rename file -> files
│   ├── 0001-build-fix-parallel-make.patch
│   ├── 0001-Check-for-limits.h-during-configure.patch
│   ├── 0001-Forward-port-to-OpenSSL-1.1.x.patch
│   ├── 0002-wvrules.mk-Use-_DEFAULT_SOURCE.patch
│   ├── 0002-wvtask-Dont-use-ucontext-on-non-glibc-systems.patch
│   ├── 0003-wvtask-Check-for-HAVE_LIBC_STACK_END-only-on-glibc-s.patch
│   ├── 0004-wvcrash-Replace-use-of-basename-API.patch
│   ├── 0005-check-for-libexecinfo-during-configure.patch
│   ├── 04_signed_request.diff
│   ├── 05_gcc.diff
│   ├── 06_gcc-4.7.diff
│   ├── 07_buildflags.diff
│   ├── argp.patch
│   ├── gcc-6.patch
│   └── openssl-buildfix.patch
└── wvstreams_4.6.1.bb

And this is the recipie file:

HOMEPAGE = "http://alumnit.ca/wiki/index.php?page=WvStreams"
SUMMARY = "WvStreams is a network programming library in C++"

LICENSE = "LGPLv2"
LIC_FILES_CHKSUM = "file://LICENSE;md5=55ca817ccb7d5b5b66355690e9abc605"

DEPENDS = "zlib openssl (>= 0.9.8) dbus readline"
DEPENDS_append_libc-musl = " argp-standalone libexecinfo"

SRC_URI = "http://${BPN}.googlecode.com/files/${BP}.tar.gz \
           file://04_signed_request.diff \
           file://05_gcc.diff \
           file://06_gcc-4.7.diff \
           file://07_buildflags.diff \
           file://gcc-6.patch \
           file://argp.patch \
           file://0001-Check-for-limits.h-during-configure.patch \
           file://0002-wvtask-Dont-use-ucontext-on-non-glibc-systems.patch \
           file://0003-wvtask-Check-for-HAVE_LIBC_STACK_END-only-on-glibc-s.patch \
           file://0004-wvcrash-Replace-use-of-basename-API.patch \
           file://0005-check-for-libexecinfo-during-configure.patch \
           file://0001-build-fix-parallel-make.patch \
           file://0002-wvrules.mk-Use-_DEFAULT_SOURCE.patch \
           file://openssl-buildfix.patch \
           file://0001-Forward-port-to-OpenSSL-1.1.x.patch \
           "

SRC_URI[md5sum] = "2760dac31a43d452a19a3147bfde571c"
SRC_URI[sha256sum] = "8403f5fbf83aa9ac0c6ce15d97fd85607488152aa84e007b7d0621b8ebc07633"

inherit autotools-brokensep pkgconfig

TARGET_CFLAGS_append = " -fno-tree-dce -fno-optimize-sibling-calls"

LDFLAGS_append = " -Wl,-rpath-link,${CROSS_DIR}/${TARGET_SYS}/lib"

EXTRA_OECONF = " --without-tcl --without-qt --without-pam --without-valgrind"

PACKAGES_prepend = "libuniconf "
PACKAGES_prepend = "uniconfd "
PACKAGES_prepend = "libwvstreams-base "
PACKAGES_prepend = "libwvstreams-extras "
PACKAGES_prepend = "${PN}-valgrind "

RPROVIDES_${PN}-dbg += "libuniconf-dbg uniconfd-dbg libwvstreams-base-dbg libwvstreams-extras-dbg"

FILES_libuniconf     = "${libdir}/libuniconf.so.*"

FILES_uniconfd     = "${sbindir}/uniconfd ${sysconfdir}/uniconf.conf ${localstatedir}/uniconf"

FILES_libwvstreams-base     = "${libdir}/libwvutils.so.*"

FILES_libwvstreams-extras     = "${libdir}/libwvbase.so.* ${libdir}/libwvstreams.so.*"

FILES_${PN}-valgrind = "${libdir}/valgrind/wvstreams.supp"
RDEPENDS_${PN} += "perl"






-- 
Maciej Pijanowski
Embedded Systems Engineer
GPG: 9963C36AAC3B2B46
https://3mdeb.com | @3mdeb_com
wvdial

Zoltan Kerenyi Nagy
 

Hi,

Here is the error now, all the files are there, it says that 04_signed_request.diff is not there:

WARNING: wvstreams-4.6.1-r0 do_fetch: Failed to fetch URL file://04_signed_request.diff, attempting MIRRORS if available
ERROR: wvstreams-4.6.1-r0 do_fetch: Fetcher failure: Unable to find file file://04_signed_request.diff anywhere. The paths that were searched were:
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/nodistro
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/nodistro
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/nodistro
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/barix-ipam400
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/barix-ipam400
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/barix-ipam400
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/sun8i
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/sun8i
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/sun8i
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/armv7ve
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/armv7ve
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/armv7ve
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/arm
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/arm
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/arm
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams-4.6.1/
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams/
    /home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/files/
    /home/kerenyiz/oe-core/build/downloads
ERROR: wvstreams-4.6.1-r0 do_fetch: Fetcher failure for URL: 'file://04_signed_request.diff'. Unable to fetch URL from any source.
ERROR: wvstreams-4.6.1-r0 do_fetch: Function failed: base_do_fetch
ERROR: Logfile of failure stored in: /home/kerenyiz/oe-core/build/tmp-glibc/work/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/wvstreams/4.6.1-r0/temp/log.do_fetch.8864
ERROR: Task (/home/kerenyiz/oe-core/build/../stuff/meta-openembedded/meta-oe/recipes-connectivity/wvstreams/wvstreams_4.6.1.bb:do_fetch) failed with exit code '1'

Here i sthe folder structure:

├── file
│   ├── 0001-build-fix-parallel-make.patch
│   ├── 0001-Check-for-limits.h-during-configure.patch
│   ├── 0001-Forward-port-to-OpenSSL-1.1.x.patch
│   ├── 0002-wvrules.mk-Use-_DEFAULT_SOURCE.patch
│   ├── 0002-wvtask-Dont-use-ucontext-on-non-glibc-systems.patch
│   ├── 0003-wvtask-Check-for-HAVE_LIBC_STACK_END-only-on-glibc-s.patch
│   ├── 0004-wvcrash-Replace-use-of-basename-API.patch
│   ├── 0005-check-for-libexecinfo-during-configure.patch
│   ├── 04_signed_request.diff
│   ├── 05_gcc.diff
│   ├── 06_gcc-4.7.diff
│   ├── 07_buildflags.diff
│   ├── argp.patch
│   ├── gcc-6.patch
│   └── openssl-buildfix.patch
└── wvstreams_4.6.1.bb

And this is the recipie file:

HOMEPAGE = "http://alumnit.ca/wiki/index.php?page=WvStreams"
SUMMARY = "WvStreams is a network programming library in C++"

LICENSE = "LGPLv2"
LIC_FILES_CHKSUM = "file://LICENSE;md5=55ca817ccb7d5b5b66355690e9abc605"

DEPENDS = "zlib openssl (>= 0.9.8) dbus readline"
DEPENDS_append_libc-musl = " argp-standalone libexecinfo"

SRC_URI = "http://${BPN}.googlecode.com/files/${BP}.tar.gz \
           file://04_signed_request.diff \
           file://05_gcc.diff \
           file://06_gcc-4.7.diff \
           file://07_buildflags.diff \
           file://gcc-6.patch \
           file://argp.patch \
           file://0001-Check-for-limits.h-during-configure.patch \
           file://0002-wvtask-Dont-use-ucontext-on-non-glibc-systems.patch \
           file://0003-wvtask-Check-for-HAVE_LIBC_STACK_END-only-on-glibc-s.patch \
           file://0004-wvcrash-Replace-use-of-basename-API.patch \
           file://0005-check-for-libexecinfo-during-configure.patch \
           file://0001-build-fix-parallel-make.patch \
           file://0002-wvrules.mk-Use-_DEFAULT_SOURCE.patch \
           file://openssl-buildfix.patch \
           file://0001-Forward-port-to-OpenSSL-1.1.x.patch \
           "

SRC_URI[md5sum] = "2760dac31a43d452a19a3147bfde571c"
SRC_URI[sha256sum] = "8403f5fbf83aa9ac0c6ce15d97fd85607488152aa84e007b7d0621b8ebc07633"

inherit autotools-brokensep pkgconfig

TARGET_CFLAGS_append = " -fno-tree-dce -fno-optimize-sibling-calls"

LDFLAGS_append = " -Wl,-rpath-link,${CROSS_DIR}/${TARGET_SYS}/lib"

EXTRA_OECONF = " --without-tcl --without-qt --without-pam --without-valgrind"

PACKAGES_prepend = "libuniconf "
PACKAGES_prepend = "uniconfd "
PACKAGES_prepend = "libwvstreams-base "
PACKAGES_prepend = "libwvstreams-extras "
PACKAGES_prepend = "${PN}-valgrind "

RPROVIDES_${PN}-dbg += "libuniconf-dbg uniconfd-dbg libwvstreams-base-dbg libwvstreams-extras-dbg"

FILES_libuniconf     = "${libdir}/libuniconf.so.*"

FILES_uniconfd     = "${sbindir}/uniconfd ${sysconfdir}/uniconf.conf ${localstatedir}/uniconf"

FILES_libwvstreams-base     = "${libdir}/libwvutils.so.*"

FILES_libwvstreams-extras     = "${libdir}/libwvbase.so.* ${libdir}/libwvstreams.so.*"

FILES_${PN}-valgrind = "${libdir}/valgrind/wvstreams.supp"
RDEPENDS_${PN} += "perl"
[PATCH yocto-autobuilder-helper] janitor: Add the systemd unit file used on the autobuilder

Michael Halstead
 

Signed-off-by: Michael Halstead <mhalstead@linuxfoundation.org>
---
janitor/ab-janitor.service | 14 ++++++++++++++
1 file changed, 14 insertions(+)
create mode 100644 janitor/ab-janitor.service

diff --git a/janitor/ab-janitor.service b/janitor/ab-janitor.service
new file mode 100644
index 0000000..5e834af
--- /dev/null
+++ b/janitor/ab-janitor.service
@@ -0,0 +1,14 @@
+# /etc/systemd/system/ab-janitor.service
+[Unit]
+Description=Autobuilder Janitor Service
+After=network-online.target
+Wants=network-online.target
+
+[Service]
+User=pokybuild
+WorkingDirectory=/home/pokybuild
+Type=simple
+ExecStart=/usr/bin/python3 /home/pokybuild/yocto-autobuilder-helper/janitor/ab-janitor
+
+[Install]
+WantedBy=multi-user.target
--
2.26.2
Re: #yocto #sdk - meta-clang undefined references #sdk #yocto

Monsees, Steven C (US)
 

Yes, I did this... I am currently down to 1 issue:


/ede/smonsees/yocto/test/beignet-Release_v1.3/backend/src/llvm/llvm_to_gen.cpp: In function ‘bool gbe::llvmToGen(gbe::ir::Unit&, const void*, int, bool, int, std::__cxx11::string&)’:
/ede/smonsees/yocto/test/beignet-Release_v1.3/backend/src/llvm/llvm_to_gen.cpp:325:68: error: no matching function for call to ‘llvm::LLVMContext::setDiagnosticHandler(void (*)(const llvm::DiagnosticInfo&, void*), gbe::gbeDiagnosticContext*)’
mod.getContext().setDiagnosticHandler(&gbeDiagnosticHandler,&dc);
^
In file included from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/Metadata.h:30:0,
from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/TrackingMDRef.h:17,
from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/DebugLoc.h:18,
from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/Instruction.h:22,
from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/BasicBlock.h:23,
from /ede/smonsees/yocto/test/beignet-Release_v1.3/backend/src/llvm/llvm_includes.hpp:30,
from /ede/smonsees/yocto/test/beignet-Release_v1.3/backend/src/llvm/llvm_to_gen.cpp:25:
/opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/LLVMContext.h:213:8: note: candidate: void llvm::LLVMContext::setDiagnosticHandler(std::unique_ptr<llvm::DiagnosticHandler>&&, bool)
void setDiagnosticHandler(std::unique_ptr<DiagnosticHandler> &&DH,
^~~~~~~~~~~~~~~~~~~~
/opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/LLVMContext.h:213:8: note: no known conversion for argument 1 from ‘void (*)(const llvm::DiagnosticInfo&, void*)’ to ‘std::unique_ptr<llvm::DiagnosticHandler>&&’
make[2]: *** [backend/src/CMakeFiles/gbe.dir/llvm/llvm_to_gen.cpp.o] Error 1
make[1]: *** [backend/src/CMakeFiles/gbe.dir/all] Error 2
make: *** [all] Error 2
11:27 smonsees@yix490016 ~/yocto/test/beignet-Release_v1.3/mybuild>

-----Original Message-----
From: Khem Raj [mailto:raj.khem@gmail.com]
Sent: Wednesday, September 16, 2020 12:32 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk - meta-clang undefined references

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


that means your link step is not linking libclang properly into your app, perhaps change the order so -lclang appears last

On Wed, Sep 16, 2020 at 4:06 AM Monsees, Steven C (US) <steven.monsees@baesystems.com> wrote:



It should be linking in libclang , I will validate...

Note performing 'nm' on libclang appear to show the majority present...

Question: if I needed to include a library, what/how would I modify a recipe under Yocto to be sure to include/link in the library ?

Thanks,
Steve

-----Original Message-----
From: Khem Raj [mailto:raj.khem@gmail.com]
Sent: Tuesday, September 15, 2020 5:06 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk - meta-clang undefined references

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


On Tue, Sep 15, 2020 at 12:56 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



I am building meta-clang (sumo based 6.0.1), with cmake (3.8.2), all
under a standard SDK “rocko based” (2.4.1)…



Are the following routines accessible/supported under meta-clang ?



libgbe.so: undefined reference to `clang::DiagnosticIDs::~DiagnosticIDs()'

libgbe.so: undefined reference to `clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_ostream&, clang::DiagnosticOptions*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::~DiagnosticsEngine()'

libgbe.so: undefined reference to `clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::~CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::PCHContainerOperations::PCHContainerOperations()'

libgbe.so: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::DiagnosticsEngine(llvm::IntrusiveRefCntPtr<clang::DiagnosticIDs>, clang::DiagnosticOptions*, clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::CodeGenOptions::CodeGenOptions()'

libgbe.so: undefined reference to `clang::CompilerInstance::~CompilerInstance()'

libgbe.so: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, clang::MemoryBufferCache*)'

libgbe.so: undefined reference to `clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(llvm::LLVMContext*)'

libgbe.so: undefined reference to `clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::CompilerInstance::setInvocation(std::shared_ptr<clang::CompilerInvocation>)'

libgbe.so: undefined reference to `clang::CodeGenAction::takeModule()'

libgbe.so: undefined reference to `clang::DiagnosticIDs::DiagnosticIDs()'
are you linking this library with libclang ? secondly, also check that
its not emitting bunch of libraries which needs to then individually
linked



thanks,

Steve
Re: #yocto #sdk - meta-clang undefined references #sdk #yocto

Khem Raj
 

that means your link step is not linking libclang properly into your
app, perhaps change the order so -lclang appears last

On Wed, Sep 16, 2020 at 4:06 AM Monsees, Steven C (US)
<steven.monsees@baesystems.com> wrote:



It should be linking in libclang , I will validate...

Note performing 'nm' on libclang appear to show the majority present...

Question: if I needed to include a library, what/how would I modify a recipe under Yocto to be sure to include/link in the library ?

Thanks,
Steve

-----Original Message-----
From: Khem Raj [mailto:raj.khem@gmail.com]
Sent: Tuesday, September 15, 2020 5:06 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk - meta-clang undefined references

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


On Tue, Sep 15, 2020 at 12:56 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



I am building meta-clang (sumo based 6.0.1), with cmake (3.8.2), all
under a standard SDK “rocko based” (2.4.1)…



Are the following routines accessible/supported under meta-clang ?



libgbe.so: undefined reference to `clang::DiagnosticIDs::~DiagnosticIDs()'

libgbe.so: undefined reference to `clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_ostream&, clang::DiagnosticOptions*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::~DiagnosticsEngine()'

libgbe.so: undefined reference to `clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::~CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::PCHContainerOperations::PCHContainerOperations()'

libgbe.so: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::DiagnosticsEngine(llvm::IntrusiveRefCntPtr<clang::DiagnosticIDs>, clang::DiagnosticOptions*, clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::CodeGenOptions::CodeGenOptions()'

libgbe.so: undefined reference to `clang::CompilerInstance::~CompilerInstance()'

libgbe.so: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, clang::MemoryBufferCache*)'

libgbe.so: undefined reference to `clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(llvm::LLVMContext*)'

libgbe.so: undefined reference to `clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::CompilerInstance::setInvocation(std::shared_ptr<clang::CompilerInvocation>)'

libgbe.so: undefined reference to `clang::CodeGenAction::takeModule()'

libgbe.so: undefined reference to `clang::DiagnosticIDs::DiagnosticIDs()'
are you linking this library with libclang ? secondly, also check that its not emitting bunch of libraries which needs to then individually linked



thanks,

Steve
Re: #yocto #sdk - meta-clang undefined references #sdk #yocto

Khem Raj
 

Can you inspect the clang libs for these symbols?

On Wed, Sep 16, 2020 at 7:04 AM Monsees, Steven C (US) via
lists.yoctoproject.org
<steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



I can see that libclang is being included...so, not sure why when linking an executable these references are missing...

-----Original Message-----
From: Monsees, Steven C (US)
Sent: Wednesday, September 16, 2020 7:06 AM
To: 'Khem Raj' <raj.khem@gmail.com>
Cc: yocto@lists.yoctoproject.org
Subject: RE: [yocto] #yocto #sdk - meta-clang undefined references



It should be linking in libclang , I will validate...

Note performing 'nm' on libclang appear to show the majority present...

Question: if I needed to include a library, what/how would I modify a recipe under Yocto to be sure to include/link in the library ?

Thanks,
Steve

-----Original Message-----
From: Khem Raj [mailto:raj.khem@gmail.com]
Sent: Tuesday, September 15, 2020 5:06 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk - meta-clang undefined references

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


On Tue, Sep 15, 2020 at 12:56 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



I am building meta-clang (sumo based 6.0.1), with cmake (3.8.2), all
under a standard SDK “rocko based” (2.4.1)…



Are the following routines accessible/supported under meta-clang ?



libgbe.so: undefined reference to `clang::DiagnosticIDs::~DiagnosticIDs()'

libgbe.so: undefined reference to `clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_ostream&, clang::DiagnosticOptions*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::~DiagnosticsEngine()'

libgbe.so: undefined reference to `clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::~CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::PCHContainerOperations::PCHContainerOperations()'

libgbe.so: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::DiagnosticsEngine(llvm::IntrusiveRefCntPtr<clang::DiagnosticIDs>, clang::DiagnosticOptions*, clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::CodeGenOptions::CodeGenOptions()'

libgbe.so: undefined reference to `clang::CompilerInstance::~CompilerInstance()'

libgbe.so: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, clang::MemoryBufferCache*)'

libgbe.so: undefined reference to `clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(llvm::LLVMContext*)'

libgbe.so: undefined reference to `clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::CompilerInstance::setInvocation(std::shared_ptr<clang::CompilerInvocation>)'

libgbe.so: undefined reference to `clang::CodeGenAction::takeModule()'

libgbe.so: undefined reference to `clang::DiagnosticIDs::DiagnosticIDs()'
are you linking this library with libclang ? secondly, also check that its not emitting bunch of libraries which needs to then individually linked



thanks,

Steve
Re: #yocto #sdk - meta-clang undefined references #sdk #yocto

Monsees, Steven C (US)
 

Found a cmake issue and fixed almost all of it, down to 1 missing reference:


/ede/smonsees/yocto/test/beignet-Release_v1.3/backend/src/llvm/llvm_to_gen.cpp: In function ‘bool gbe::llvmToGen(gbe::ir::Unit&, const void*, int, bool, int, std::__cxx11::string&)’:
/ede/smonsees/yocto/test/beignet-Release_v1.3/backend/src/llvm/llvm_to_gen.cpp:325:68: error: no matching function for call to ‘llvm::LLVMContext::setDiagnosticHandler(void (*)(const llvm::DiagnosticInfo&, void*), gbe::gbeDiagnosticContext*)’
mod.getContext().setDiagnosticHandler(&gbeDiagnosticHandler,&dc);
^
In file included from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/Metadata.h:30:0,
from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/TrackingMDRef.h:17,
from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/DebugLoc.h:18,
from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/Instruction.h:22,
from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/BasicBlock.h:23,
from /ede/smonsees/yocto/test/beignet-Release_v1.3/backend/src/llvm/llvm_includes.hpp:30,
from /ede/smonsees/yocto/test/beignet-Release_v1.3/backend/src/llvm/llvm_to_gen.cpp:25:
/opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/LLVMContext.h:213:8: note: candidate: void llvm::LLVMContext::setDiagnosticHandler(std::unique_ptr<llvm::DiagnosticHandler>&&, bool)
void setDiagnosticHandler(std::unique_ptr<DiagnosticHandler> &&DH,
^~~~~~~~~~~~~~~~~~~~
/opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/LLVMContext.h:213:8: note: no known conversion for argument 1 from ‘void (*)(const llvm::DiagnosticInfo&, void*)’ to ‘std::unique_ptr<llvm::DiagnosticHandler>&&’
make[2]: *** [backend/src/CMakeFiles/gbe.dir/llvm/llvm_to_gen.cpp.o] Error 1
make[1]: *** [backend/src/CMakeFiles/gbe.dir/all] Error 2
make: *** [all] Error 2
11:27 smonsees@yix490016 ~/yocto/test/beignet-Release_v1.3/mybuild>

-----Original Message-----
From: yocto@lists.yoctoproject.org [mailto:yocto@lists.yoctoproject.org] On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Wednesday, September 16, 2020 10:05 AM
To: Khem Raj <raj.khem@gmail.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk - meta-clang undefined references

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.



I can see that libclang is being included...so, not sure why when linking an executable these references are missing...

-----Original Message-----
From: Monsees, Steven C (US)
Sent: Wednesday, September 16, 2020 7:06 AM
To: 'Khem Raj' <raj.khem@gmail.com>
Cc: yocto@lists.yoctoproject.org
Subject: RE: [yocto] #yocto #sdk - meta-clang undefined references



It should be linking in libclang , I will validate...

Note performing 'nm' on libclang appear to show the majority present...

Question: if I needed to include a library, what/how would I modify a recipe under Yocto to be sure to include/link in the library ?

Thanks,
Steve

-----Original Message-----
From: Khem Raj [mailto:raj.khem@gmail.com]
Sent: Tuesday, September 15, 2020 5:06 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk - meta-clang undefined references

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


On Tue, Sep 15, 2020 at 12:56 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



I am building meta-clang (sumo based 6.0.1), with cmake (3.8.2), all
under a standard SDK “rocko based” (2.4.1)…



Are the following routines accessible/supported under meta-clang ?



libgbe.so: undefined reference to `clang::DiagnosticIDs::~DiagnosticIDs()'

libgbe.so: undefined reference to `clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_ostream&, clang::DiagnosticOptions*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::~DiagnosticsEngine()'

libgbe.so: undefined reference to `clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::~CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::PCHContainerOperations::PCHContainerOperations()'

libgbe.so: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::DiagnosticsEngine(llvm::IntrusiveRefCntPtr<clang::DiagnosticIDs>, clang::DiagnosticOptions*, clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::CodeGenOptions::CodeGenOptions()'

libgbe.so: undefined reference to `clang::CompilerInstance::~CompilerInstance()'

libgbe.so: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, clang::MemoryBufferCache*)'

libgbe.so: undefined reference to `clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(llvm::LLVMContext*)'

libgbe.so: undefined reference to `clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::CompilerInstance::setInvocation(std::shared_ptr<clang::CompilerInvocation>)'

libgbe.so: undefined reference to `clang::CodeGenAction::takeModule()'

libgbe.so: undefined reference to `clang::DiagnosticIDs::DiagnosticIDs()'
are you linking this library with libclang ? secondly, also check that its not emitting bunch of libraries which needs to then individually linked



thanks,

Steve
Re: [meta-security][PATCH 2/2] apparmor: exclude mips, not supported

akuster
 

On 9/15/20 10:11 PM, Khem Raj wrote:
title says mips but it actually is for mips64 only it seems.
right. easy to fix when I commit. Have not built qemumip so its unknown
at this time.

-armin

On Tue, Sep 15, 2020 at 8:12 PM akuster <akuster808@gmail.com> wrote:
Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-mac/AppArmor/apparmor_2.13.4.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-mac/AppArmor/apparmor_2.13.4.bb b/recipes-mac/AppArmor/apparmor_2.13.4.bb
index 552cac7..dcdc1f7 100644
--- a/recipes-mac/AppArmor/apparmor_2.13.4.bb
+++ b/recipes-mac/AppArmor/apparmor_2.13.4.bb
@@ -30,6 +30,8 @@ S = "${WORKDIR}/git"

PARALLEL_MAKE = ""

+COMPATIBLE_MACHINE_mips64 = "(!.*mips64).*"
+
inherit pkgconfig autotools-brokensep update-rc.d python3native perlnative ptest cpan manpages systemd features_check
REQUIRED_DISTRO_FEATURES = "apparmor"

--
2.17.1
Re: #yocto #sdk - meta-clang undefined references #sdk #yocto

Monsees, Steven C (US)
 

I can see that libclang is being included...so, not sure why when linking an executable these references are missing...

-----Original Message-----
From: Monsees, Steven C (US)
Sent: Wednesday, September 16, 2020 7:06 AM
To: 'Khem Raj' <raj.khem@gmail.com>
Cc: yocto@lists.yoctoproject.org
Subject: RE: [yocto] #yocto #sdk - meta-clang undefined references



It should be linking in libclang , I will validate...

Note performing 'nm' on libclang appear to show the majority present...

Question: if I needed to include a library, what/how would I modify a recipe under Yocto to be sure to include/link in the library ?

Thanks,
Steve

-----Original Message-----
From: Khem Raj [mailto:raj.khem@gmail.com]
Sent: Tuesday, September 15, 2020 5:06 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk - meta-clang undefined references

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


On Tue, Sep 15, 2020 at 12:56 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



I am building meta-clang (sumo based 6.0.1), with cmake (3.8.2), all
under a standard SDK “rocko based” (2.4.1)…



Are the following routines accessible/supported under meta-clang ?



libgbe.so: undefined reference to `clang::DiagnosticIDs::~DiagnosticIDs()'

libgbe.so: undefined reference to `clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_ostream&, clang::DiagnosticOptions*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::~DiagnosticsEngine()'

libgbe.so: undefined reference to `clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::~CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::PCHContainerOperations::PCHContainerOperations()'

libgbe.so: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::DiagnosticsEngine(llvm::IntrusiveRefCntPtr<clang::DiagnosticIDs>, clang::DiagnosticOptions*, clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::CodeGenOptions::CodeGenOptions()'

libgbe.so: undefined reference to `clang::CompilerInstance::~CompilerInstance()'

libgbe.so: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, clang::MemoryBufferCache*)'

libgbe.so: undefined reference to `clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(llvm::LLVMContext*)'

libgbe.so: undefined reference to `clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::CompilerInstance::setInvocation(std::shared_ptr<clang::CompilerInvocation>)'

libgbe.so: undefined reference to `clang::CodeGenAction::takeModule()'

libgbe.so: undefined reference to `clang::DiagnosticIDs::DiagnosticIDs()'
are you linking this library with libclang ? secondly, also check that its not emitting bunch of libraries which needs to then individually linked



thanks,

Steve
Re: #yocto #sdk - meta-clang undefined references #sdk #yocto

Monsees, Steven C (US)
 

It should be linking in libclang , I will validate...

Note performing 'nm' on libclang appear to show the majority present...

Question: if I needed to include a library, what/how would I modify a recipe under Yocto to be sure to include/link in the library ?

Thanks,
Steve

-----Original Message-----
From: Khem Raj [mailto:raj.khem@gmail.com]
Sent: Tuesday, September 15, 2020 5:06 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk - meta-clang undefined references

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


On Tue, Sep 15, 2020 at 12:56 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



I am building meta-clang (sumo based 6.0.1), with cmake (3.8.2), all
under a standard SDK “rocko based” (2.4.1)…



Are the following routines accessible/supported under meta-clang ?



libgbe.so: undefined reference to `clang::DiagnosticIDs::~DiagnosticIDs()'

libgbe.so: undefined reference to `clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_ostream&, clang::DiagnosticOptions*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::~DiagnosticsEngine()'

libgbe.so: undefined reference to `clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::~CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::PCHContainerOperations::PCHContainerOperations()'

libgbe.so: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::DiagnosticsEngine(llvm::IntrusiveRefCntPtr<clang::DiagnosticIDs>, clang::DiagnosticOptions*, clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::CodeGenOptions::CodeGenOptions()'

libgbe.so: undefined reference to `clang::CompilerInstance::~CompilerInstance()'

libgbe.so: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, clang::MemoryBufferCache*)'

libgbe.so: undefined reference to `clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(llvm::LLVMContext*)'

libgbe.so: undefined reference to `clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::CompilerInstance::setInvocation(std::shared_ptr<clang::CompilerInvocation>)'

libgbe.so: undefined reference to `clang::CodeGenAction::takeModule()'

libgbe.so: undefined reference to `clang::DiagnosticIDs::DiagnosticIDs()'
are you linking this library with libclang ? secondly, also check that its not emitting bunch of libraries which needs to then individually linked



thanks,

Steve
1881 - 1900 of 52573