The recipe produces static archives only, and does not compile them PIC, so
linking capnp or kj into a shared library fails:
libkj.a(exception.c++.o): relocation R_X86_64_TPOFF32 against
`kj::(anonymous namespace)::threadLocalCallback' can not be used when making
a shared object; local-exec is incompatible with -shared
kj/exception.c++ has a file-scope thread_local, which non-PIC code compiles to
the local-exec TLS model. A shared object cannot use that model, so the link
fails on any consumer that puts capnp inside a .so. Debian and Fedora do not
hit this because they ship shared libcapnp.
Set CMAKE_POSITION_INDEPENDENT_CODE. Packaging is unchanged: still static,
still no .so, no new packages and no ABI surface, only the code model differs.
Signed-off-by: Joel Winarske <joel.winarske@gmail.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
Cap'n Proto 1.5.0 is primarily a KJ-HTTP security release. It hardens
the plain-HTTP serialization path against request smuggling / HTTP
desync: serializeRequest/serializeConnectRequest now reject request
targets containing whitespace or control characters and serializeResponse
rejects status text containing CR, LF or NUL (GHSL-2026-146, reported by
Kevin Stubbings), and the header parser no longer accepts whitespace
between a field name and the colon. It also picks up compatibility
fixes: builds against OpenSSL 4.0 while remaining compatible with older
OpenSSL, Bazel 9 support, boringssl Bzlmod repo_name, an MSVC build fix,
tolerating ERROR_INVALID_FUNCTION from GetFileInformationByHandleEx under
Wine, replacing the c++/LICENSE.txt symlink with a real file, and
scoping CTest to the project. LICENSE is unchanged and
0001-Export-binaries-only-for-native-build.patch still applies cleanly.
AI-Generated: Uses Claude Code
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
Please see
https://git.yoctoproject.org/poky/commit/?id=4dd321f8b83afecd962393101b2a6861275b5265
for what changes are needed, and sed commands that can be used to make them en masse.
I've verified that bitbake -c patch world works with these, but did not run a world
build; the majority of recipes shouldn't need further fixups, but if there are
some that still fall out, they can be fixed in followups.
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
The base problem this is trying to solve: capnproto has two main
components: libraries that can be linked against, and binary files
that can generate c++ code from capnproto definitions. When cross-compiling
one needs to use the cross-compiled libraries, but with the native
definition-compilers.
When linking against capnproto from another recipe, cross-compilation
fails, because the cmake files generated by capnproto verify the
existence of binary files in $bindir. When using a cross-compiled
version of capnproto, these binary files do not exist in RECIPE_SYSROOT, so
the compilation fails.
The previous patch: the previous solution patched the CMakeLists.txt
file in a way that it didn't export nor install the generated binary files.
Accidentally this also happened with native build (and happened knowingly with
target builds).
The new patch: instead of not installing and not exporting the binaries,
just install them without exporting, when creating a target build.
During compilation check is CMAKE_CROSSCOMPILING is set (coming from
cmake.bbclass) - if it is set, only install the binaries, without
exporting. When it is not set, resort to the original behavior.
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
When linking to capnproto from another project, cmake fails to
find this package with the following error:
| CMake Error at ${RECIPE_SYSROOT}/usr/lib/cmake/CapnProto/CapnProtoTargets.cmake:176 (message):
| The imported target "CapnProto::capnp_tool" references the file
|
| "${RECIPE_SYSROOT}/usr/bin/capnp"
|
| but this file does not exist. Possible reasons include:
To solve this, this change includes the following:
1. Add a patch that removes the files installed (and exported) in
${bindir} from the target build. The CMake file originally verified
that these files exist when another recipe tried to use it, however
the ${RECIPE_SYSROOT} does not contain the binaries in ${bindir},
so it failed quick in the do_configure step. (This alone is enough
to link against the cross-compiled libraries of capnproto successfully,
but code-generation from capnproto definition fails)
2. Add a new bbclass for capnproto. To cross-compile an application
that uses capnproto, the application needs to be linked against the
cross-compiled version of the libraries, however the native version
of the binaries need to be used to generate C++ code from the
capnproto definitions. This class sets the correct CMake arguments, to
use the capnproto binaries from the native package, instead of looking
for the non-existent cross-compiled binaries. (These variables can
be found in ${libdir}/cmake/CapnProto/CapnProtoConfig.cmake file)
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This patch updates SRC_URIs using git to include branch=master if no branch is set
and also to use protocol=https for github urls as generated by the conversion script
in OE-Core.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This is the result of automated script (0.9.1) conversion:
oe-core/scripts/contrib/convert-overrides.py .
converting the metadata to use ":" as the override character instead of "_".
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
License checksum changed due to minor change to the LICENSE file
mentioning other contributors (see @64db3a6def96453f775d).
Signed-off-by: Oleksandr Kravchuk <open.source@oleksandr-kravchuk.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>