Commit 1d14ef82f4 does not completely fix
the build with python 3.8 as we still get link failure due to
'-z undefs' being ignored by some versions of ld.
Indeed, -z undefs was added by commit
97a232d7335f3bd0231fd9cd39455bde1d563922 in upstream binutils, and this
commit was first present in binutils 2.30.
So any toolchain using binutils version older than that won't have
-z undefs and will build fail on:
/home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/mips-linux-gnu/5.3.0/../../../../mips-linux-gnu/bin/ld: warning: -z undefs ignored.
/home/naourr/work/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/aarch64_be-linux-gnu/7.3.1/../../../../aarch64_be-linux-gnu/bin/ld: warning: -z undefs ignored.
So filter -Wl,--no-undefined to fix the issue
Fixes:
- http://autobuild.buildroot.org/results/e9645d9969481b09f507f6e0d0b35faaa283eb60
- http://autobuild.buildroot.org/results/06a6d865b6b7d8ebd793bde214f4a4c40e0962e1
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
kmod's configure.ac uses the -Wl,--no-undefined linker flag to verify
at link time that all symbols of shared libraries are available, and
that there are no undefined symbols.
This make perfect sense for regular shared libraries. However, for
Python extensions, which will be dlopen()ed inside the Python
interpreter, it makes less sense.
Since Python 3.8, there is a change in python-config script and
Python's pkg-config file: it no longer links Python extensions with
the libpython library. See
https://docs.python.org/dev/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build
which states:
On the other hand, pkg-config python3.8 --libs no longer contains
-lpython3.8. C extensions must not be linked to libpython (except on
Android and Cygwin, whose cases are handled by the script); this
change is backward incompatible on purpose. (Contributed by Victor
Stinner in bpo-36721.)
So, when linking the kmod Python extensions, it currently fails with
numerous unresolved symbols, that were previously provided by
libpython:
/home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64-buildroot-linux-gnu/7.4.0/../../../../powerpc64-buildroot-linux-gnu/bin/ld: libkmod/python/kmod/.libs/list_la-list.o: in function `__Pyx_PyObject_GetAttrStr':
list.c:(.text.__Pyx_PyObject_GetAttrStr+0x48): undefined reference to `PyObject_GetAttr'
/home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64-buildroot-linux-gnu/7.4.0/../../../../powerpc64-buildroot-linux-gnu/bin/ld: libkmod/python/kmod/.libs/list_la-list.o: in function `__pyx_tp_dealloc_4kmod_4list_ModListItem':
list.c:(.text.__pyx_tp_dealloc_4kmod_4list_ModListItem+0x78): undefined reference to `PyObject_CallFinalizerFromDealloc'
/home/test/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64-buildroot-linux-gnu/7.4.0/../../../../powerpc64-buildroot-linux-gnu/bin/ld: libkmod/python/kmod/.libs/list_la-list.o: in function `__pyx_tp_dealloc_4kmod_4list_ModList':
list.c:(.text.__pyx_tp_dealloc_4kmod_4list_ModList+0x30): undefined reference to `PyErr_Fetch'
[Complete log at http://autobuild.buildroot.net/results/79a/79a5a0398723e8cfea0d0aa3dec5f7649aee4c63/build-end.log]
Linking with libpython is no longer recommended: those symbols should
remain unresolved in the Python extensions, as they wil be properly
resolved when the Python extension gets loaded into the Python
interpreter.
Since we want to keep -Wl,--no-undefined globally in kmod, we leave
the configure.ac file unchanged, and instead, specifically in the
LDFLAGS used to build the Python extensions, we override
-Wl,--no-undefined with -Wl,-z,undefs. Ideally, -Wl,--no-undefined is
the same as -Wl,-z,defs, and the effect of these options can be
canceled on the linker command line by a following -Wl,-z,undefs (see
the ld man page for details).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Victor Stinner <victor.stinner@gmail.com>
In the previous build setup, libkmod.so would link to not just
libcrypto.so, but also libssl.so:
$ readelf -d /lib/libkmod.so | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [liblzma.so.5]
0x0000000000000001 (NEEDED) Shared library: [libz.so.1]
0x0000000000000001 (NEEDED) Shared library: [libssl.so.1.1]
0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
We don't need any symbols from libssl, though. This patch ensures that
we pass 'libcrypto' to pkgconfig rather than 'openssl', getting only the
library that we need:
$ readelf -d ./libkmod/.libs/libkmod.so.2.3.4 | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [liblzma.so.5]
0x0000000000000001 (NEEDED) Shared library: [libz.so.1]
0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
The patch adds data fetching from the PKCS#7 certificate using
openssl library (which is used by scripts/sign-file.c in the linux
kernel to sign modules).
In general the certificate can contain many signatures, but since
kmod (modinfo) supports only one signature at the moment, only first
one is taken.
With the current sign-file.c certificate doesn't contain signer
key's fingerprint, so "serial number" is used for the key id.
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
Let's just use autogen.sh, no need for wrapper scripts. Now
`autogen.sh c` uses the same recommended options for developing kmod and
also accepts extra arguments.
Instead of using the mkosi.default symlink, use an env var passed from
the build system. We would need to pass the --default switch nonetheless
or change the symlink, making the git tree dirty.
Also, search for installed kernel headers in a way that's compatible
with more distros. On Fedora, for example, the
/usr/lib/modules/<kver>/build symlink is only available if there's a
kernel installed. We don't care about a kernel installed since we don't
need to boot it on a real machine: the only thing we need is the
kernel-devel package.
The patch adds nested loops configuration for the loop test:
mod-loop-h -> mod-loop-i -> mod-loop-j -> mod-loop-k
^ | |
--------------------------- |
| |
-------------------------------------------
making 2 loops with common edges:
mod-loop-h -> mod-loop-i -> mod-loop-j -> mod-loop-h
mod-loop-h -> mod-loop-i -> mod-loop-j -> mod-loop-k -> mod-loop-h
The actual output for the loops is:
depmod: ERROR: Cycle detected: mod_loop_h -> mod_loop_h
depmod: ERROR: Cycle detected: mod_loop_i -> mod_loop_j -> mod_loop_k -> mod_loop_h -> mod_loop_i
(the order in the second doesn't matter, but the first one is
incorrect)
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
install: cannot stat 'testsuite/module-playground/mod-loop-f.ko': No
such file or directory
Makefile:2881: recipe for target 'rootfs' failed
make[1]: *** [rootfs] Error 1
make[1]: *** Waiting for unfinished jobs....
Makefile:2101: recipe for target 'check-recursive' failed
We need to ship pre-compiled binaries so it's possible to run
"make check" on servers without kernel headers.
Also add them to EXTRA_DIST as other sources.
This should fill the requirements for "we need to loop over a lot of
strings that usually are small enough to remain on stack, but we want to
protect ourselves against huge strings not fitting in the static
buffer we estimated as sufficient"
Makefile.am uses `sed -E', which it is found on BSD sed; however a
replacement on GNU sed would be `sed -r'. Both intend to use extended
regular expressions (ERE). However I have a system that does not support
those, in benefit for portability could you consider replacing ERE by BRE.
Signed-off-by: Héctor Orón Martínez <hector.oron@gmail.com>
Use POSIX Extended Regular Expression (ERE) instead of the GNU extension
\| in the install-exec-hook. This makes it create the symlink properly
with busybox sed built with musl libc. It will silently create a broken
symlink otherwise.
Lucas De Marchi: fix up added newline.
We try to execute git in order to get the dependencies for the coverity
rules. And it gets executed even when we are not calling that specific
rule. Later we may want to improve it, but for now let's just silence
the errors of not being a git repository when executing this on a
packaged version.
Now that we are able to build our own test modules, also allow to use
cached modules so a) kernel headers are not required and b) distro
maintainers are happy. It's still need a "--disable-test-modules" in
the configure since the default is enabled.
There's no license problems anymore since all modules come from our own
repository, we ship the sources and the modules can be easily rebuilt.
Usually this file is added to keep a directory existing in the
repository but without any real content. In rootfs this can be
problematic if a directory will have all its files inspected. This
happens for kmod_module_get_holders().
Side-note: the 'test-loaded.c' is hit by this problem but doesn't
"notice" because the invalid module returned by get_holders() is not
checked. The modules in its loop are only used to get the name and
generate an output, and NULL was a valid value to generate the name.
The second test, that creates the module by name and then retrieves the
initstate was broken before b95fa91 ('Fix race while loading modules').
We would check /sys and return either builtin (if the module has
parameters) or give an error because we don't find the module (even if
it's in the modules.builtin index)
We need to let these instructions in kmod to be the last executed ones.
Otherwise the subdirectory containing the modules could propagate up the
time access.
Instead of shipping pre-compiled module, this prepares the build system
to be able to compile the necessary modules from module-playground. This
preparations starts by replacing md5.ko with our own dummy
mod-simple.ko, built from source. It works by copying the modules to
their final location while preparing the rootfs.
Some tests cover internal API that wasn't used
elsewhere. The choice here was to test and keep the
list implementation complete instead of removing it.
If we are accessing a file inside the build directory we should really
not trap the path. Right now this isn't important because we never do
such accesses. However it will be needed when gcov is integrated because
it dumps files to the same place where the binaries are located.
The -fdiagnostics-color flag is only available on GCC >= 4.9, for
older versions this could raise an error in certain circumstances
(such as when using ccache). Instead, since -fdiagnostic-color=auto
by default in gcc-4.9, simply set the required environment variable
to the default one if it's undefined.
Based mostly on the systemd commit f44541bc by Michal Schmidt.
