* many configure tests (which might not fail before) are failing with gcc-14:
# grep implicit build/config.log
conftest.c:47:1: error: return type defaults to 'int' [-Wimplicit-int]
conftest.c:47:1: error: return type defaults to 'int' [-Wimplicit-int]
conftest.c:47:1: error: return type defaults to 'int' [-Wimplicit-int]
conftest.c:47:1: error: return type defaults to 'int' [-Wimplicit-int]
conftest.c:47:1: error: return type defaults to 'int' [-Wimplicit-int]
conftest.c:47:1: error: return type defaults to 'int' [-Wimplicit-int]
conftest.c:50:17: error: implicit declaration of function 'exit' [-Wimplicit-function-declaration]
conftest.c:50:17: warning: incompatible implicit declaration of built-in function 'exit' [-Wbuiltin-declaration-mismatch]
conftest.c:53:9: error: implicit declaration of function 'msem_init' [-Wimplicit-function-declaration]
conftest.c:54:9: error: implicit declaration of function 'msem_lock' [-Wimplicit-function-declaration]
conftest.c:55:9: error: implicit declaration of function 'msem_unlock' [-Wimplicit-function-declaration]
conftest.c:56:9: error: implicit declaration of function 'exit' [-Wimplicit-function-declaration]
conftest.c:56:9: warning: incompatible implicit declaration of built-in function 'exit' [-Wbuiltin-declaration-mismatch]
conftest.c:50:9: error: implicit declaration of function '_spin_lock_try' [-Wimplicit-function-declaration]
conftest.c:51:9: error: implicit declaration of function '_spin_unlock' [-Wimplicit-function-declaration]
* I have noticed this on db-native build on host with gcc-14
where it caused fatal do_configure error:
http://errors.yoctoproject.org/Errors/Details/784164/
checking for mutexes... UNIX/fcntl
configure: error: Support for FCNTL mutexes was removed in BDB 4.8.
the config.log confirms it's because implicit-int:
configure:22798: checking for mutexes
configure:22925: gcc -o conftest -isystem/OE/build/oe-core/tmp-glibc/work/x86_64-linux/db-native/5.3.28/recipe-sysroot-native/usr/include -O2 -pipe -isystem/OE/build/oe-core/tmp-glibc/work/x86_64-linux/db-native/5.3.28/recipe-sysroot-native/usr/include -D_GNU_SOURCE -D_REENTRANT -L/OE/build/oe-core/tmp-glibc/work/x86_64-linux/db-native/5.3.28/recipe-sysroot-native/usr/lib -L/OE/build/oe-core/tmp-glibc/work/x86_64-linux/db-native/5.3.28/recipe-sysroot-native/lib -Wl,--enable-new-dtags -Wl,-rpath-link,/OE/build/oe-core/tmp-glibc/work/x86_64-linux/db-native/5.3.28/recipe-sysroot-native/usr/lib -Wl,-rpath-link,/OE/build/oe-core/tmp-glibc/work/x86_64-linux/db-native/5.3.28/recipe-sysroot-native/lib -Wl,-rpath,/OE/build/oe-core/tmp-glibc/work/x86_64-linux/db-native/5.3.28/recipe-sysroot-native/usr/lib -Wl,-rpath,/OE/build/oe-core/tmp-glibc/work/x86_64-linux/db-native/5.3.28/recipe-sysroot-native/lib -Wl,-O1 conftest.c -lpthread >&5
conftest.c:47:1: error: return type defaults to 'int' [-Wimplicit-int]
47 | main() {
| ^~~~
configure:22925: $? = 1
configure: program exited with status 1
* comparing target db with and without this change shows following diff
in log.do_configure:
db $ diff 5.3.28*/temp/log.do_configure
268c268
< checking for mutexes... POSIX/pthreads/library
---
> checking for mutexes... POSIX/pthreads/library/x86_64/gcc-assembly
271c271
< checking for atomic operations... no
---
> checking for atomic operations... x86/gcc-assembly
(From OE-Core rev: 4d3ce333c10fadf746b6d8b55a88777c97e11ffa)
(From OE-Core rev: 277b5ec3c0212ca8600dd89d0a33f784a060131f)
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 6108da955e7c553247ff5356cf1c990b3d334edf)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
libtool is now longer renamed to ${host}-libtool, so remove the changes
to support this.
(From OE-Core rev: 291654cb31ff3568f278d143510f1e9fac573966)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is the result of automated script conversion:
scripts/contrib/convert-overrides.py <oe-core directory>
converting the metadata to use ":" as the override character instead of "_".
(From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update CVE_PRODUCT to also include 'berkeley_db'. For example,
CVE-2020-2981 uses 'berkeley_db'.
(From OE-Core rev: ad799b109716ccd2f44dcf7a6a4cfcbd622ea661)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On target, when running `db_verify /var/lib/rpm/Packages', we get
the following error.
db_verify: BDB0571 library build did not include support for database verification
This is because db_verify is installed but 'verify' PACKAGECONFIG is
not enabled. So fix it by not installing do_verify in such case.
(From OE-Core rev: b5ffdb296f211403f987b5d5a724a94ee91dc80c)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add "dbm" packageconfig to enable legacy dbm support in libdb. This support is
needed to build libpam pam_userdb.so plugin.
(From OE-Core rev: 841573cea6d06dcba45227a8126153b0629b1b0c)
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This should fix the vdso crashes seen with kernel 5.0+
python3[11312] general protection fault ip:b7e966b0 sp:bf8175cc error:0 in libc.so[b7e8b000+6b000]
(From OE-Core rev: a85afec1115f2a09cd750a4554f44fb8af96975c)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Change all recipes to https where we get an http 301 permanent redirect.
(From OE-Core rev: e514acda9e12bccde6d3974e0fd1a37b3837191a)
Signed-off-by: Stefan Müller-Klieser <s.mueller-klieser@phytec.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add switch for building database verification, enable
this, it will solve the following issue:
root@qemux86-64:~# db_verify /var/lib/rpm/Packages
db_verify: BDB0571 library build did not include support for database verification
BDB5105 Verification of /var/lib/rpm/Packages failed.
(From OE-Core rev: a785157c7d78bd4becdc03c93a21a5dba37015b9)
Signed-off-by: Wenlin Kang <wenlin.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a genuine error that is discovered when using libc++ runtime
(From OE-Core rev: e4aa17ddc2ea623de2803efa9ab2fca498c99e19)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Although the ARM SWP instruction may exist for ARMv6 and above, it's
not guaranteed to work, especially on SMP systems where it's use may
lead to instability at runtime, etc:
https://community.arm.com/processors/b/blog/posts/locks-swps-and-two-smoking-barriers
Keeping the optimisation for architecture levels which pre-date SMP
(ie <= ARMv5) may be safe, however other distros (Buildroot, Debian,
Fedora, etc) are not doing so and mutex contention is likely to be
less of an issue on uniprocessor systems anyway, so the benefits of
this micro optimisations are not clear. Since OE uses ARMv5 qemu as
a proxy for testing all 32bit ARM architecture levels, it's desirable
to keep the ARMv5 builds aligned with later ARM architecture levels
wherever possible.
(From OE-Core rev: 7aa94abac09be6beb7ce14a2b9a409e934465706)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We may ship db 5.3.28, but the CVE database knows this as oracle_berkeley_db
11.2.5.3.28.
(From OE-Core rev: f348cd641416d2750dfec8e19bd01e7ae9f809aa)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As there are no alternative providers for virtual/db remove the PROVIDES and
recipes can just depend on db.
(From OE-Core rev: dcbc45aa3fe72c528fe4d47a783da4b4ed5ff38e)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Triggered by looking at why Python doesn't find db.h (because it greps db.h for
a regex, and db.h is actually a oe_multilib_header wrapper) I realised that the
only reason we have to oe_multilib_header db.h is because one typedef is
different between 32-bit and 64-bit architectures.
However, the typedef is for a 64-bit integer so instead of using long (64-bit)
or long long (32-bit), just use int64_t. Some of the overly complicated
configure tests need to be deleted after this change but that is safe as we're
building in a controlled environment and can assume int64_t exists.
With this done the header doesn't change between architectures, and it doesn't
need to be wrapped by oe_multilib_header.
(From OE-Core rev: 60aa20b8b691e5a72a6a11bf795b86c6359db886)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix do_configure to be able to regenerate configure files
Use cross libtool as installed by OE, as done in normal autotooled recipes
These changes help in invoking the libtool with proper tags for C
and C++ compiler and linker invocation and not use same tag across all
different invocations
Fixes errors like
libtool: compile: unable to infer tagged configuration
libtool: compile: specify a tag with `--tag'
(From OE-Core rev: afa9f769d62034d4443dfe929422d1d591adf709)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Version 6.x of Berkeley DB has been rejected by open source community due to its hostile
AGPLv3 license; both Fedora and Debian are sticking with db 5.x - and by extension,
all the open source projects are still developed and tested with db 5.x
In oe-core the only thing that was requiring db 6.x was rpm 5.x, and so there's no reason
to continue carrying db 6.x in oe-core. If someone needs API features that are only available in
db 6.x, it can be re-added to meta-oe.
(From OE-Core rev: 2694de76542840f79e3953c546d07b8ae479b8a1)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Reintroduce the use of cross-libtool when building the target package
this fails otherwise with clang
| ./libtool --mode=execute true db_printlog
| /usr/lib/libstdc++.so: file not recognized: File format not recognized
| clang-3.9: error: linker command failed with exit code 1 (use -v to see invocation)
(From OE-Core rev: f9fab69a15a71f541f93fb38319de03ad07b1bf5)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of setting S to a directory inside the tarball and B to another
directory inside the tarball, use the default value of S and set
AUTOTOOLS_SCRIPT_PATH to the right path to find configure. Update the patches
so they still apply, and clean up the recipe slightly.
Because something is not quite right regarding quilt and patching, add a PR bump
to the recipes to ensure that a clean work directory is used: for some reason
rebuilds will rarely fail to patch correctly.
(From OE-Core rev: dcbef72b8344c22617d65ea1e9f0fa7ad9a742bd)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The previous HOMEPAGE is no longer available.
(From OE-Core rev: 24eba6f321e1152bcf60bc16ec21b0b29ab21179)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
db is not reconfigured like usual autotools based components so it
generates its own libtool, and this libtool is not equipped to do cross
builds, e.g. when building using clang on musl, it misdirects linker to
use libstdc++.so from build host instead of target, the reason being it
does not understand sysroot.
Use cross libtool instead to build the target versions
Fixes errors like below
| libtool: link: arm-oe-linux-musleabi-ranlib .libs/libdb-6.0.a
|
/a/builder/mnt/build-oe/tmp-musl/sysroots/x86_64-linux/usr/bin/arm-oe-linux-musleabi/arm-oe-linux-musleabi-ld:
error: /usr/lib/libstdc++.so: incompatible target
(From OE-Core rev: d14b5e650e1e55e30abbd884a6bbd9b4feacd923)
(From OE-Core rev: 22e8a0cb730b7ff8b8ce4c409548b41ffd320dde)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Because $S is set to sub-directory of db-5.3.28.
So modify SPDX_S to the source tree of db-5.3.28 instead of ${S}.
(From OE-Core rev: c86137e2fc9faee1146e41fa4b7c1d284dd6673f)
Signed-off-by: leimaohui <leimaohui@cn.fujitsu.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Simple upgrade, the license checksum change is related to a copyright date
change.
(From OE-Core rev: cc6223d24bfd85240399272ebf5f1dddb6150c79)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
