[Buildroot] [PATCH 1/1] package/libselinux: fix build with python 3.8
Thomas Petazzoni
thomas.petazzoni at bootlin.com
Tue Oct 22 07:45:00 UTC 2019
Hello,
On Tue, 22 Oct 2019 09:40:25 +0200
Thomas Petazzoni <thomas.petazzoni at bootlin.com> wrote:
> So as you can see linking against libpython is *not* the solution, it
> is just a workaround for another real problem. I have not found (yet)
> what is the problem with the versioning script, but I guess we should
> research in this direction.
So, it is not the versioning script. In fact, when testing I removed
both the --version-script option and the -z defs option. But it is
actually the -z defs option that causes the problem.
And indeed:
-z defs
Report unresolved symbol references from regular object
files. This is done even if the linker is creating a
non-symbolic shared library. The switch
--[no-]allow-shlib-undefined controls the behaviour for
reporting unresolved references found in shared libraries
being linked in.
Using -z defs in this particular case doesn't make any sense: we do
acknowledge that we can have remaining unresolved symbols. Then will be
provided by the Python interpreter.
So I believe the right fix is:
+++ src/Makefile 2019-10-22 09:44:26.700158005 +0200
@@ -165,7 +165,7 @@
$(CC) $(filter-out -Werror, $(CFLAGS)) $(PYINC) -fPIC -DSHARED -c -o $@ $<
$(AUDIT2WHYSO): $(AUDIT2WHYLOBJ) $(LIBSEPOLA)
- $(CC) $(CFLAGS) $(LDFLAGS) -L. -shared -o $@ $^ -lselinux $(LDLIBS_LIBSEPOLA) $(PYLIBS) -Wl,-soname,audit2why.so,--version-script=audit2why.map,-z,defs
+ $(CC) $(CFLAGS) $(LDFLAGS) -L. -shared -o $@ $^ -lselinux $(LDLIBS_LIBSEPOLA) $(PYLIBS) -Wl,-soname,audit2why.so,--version-script=audit2why.map
%.o: %.c policy.h
$(CC) $(CFLAGS) $(TLSFLAGS) -c -o $@ $<
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
More information about the buildroot
mailing list