selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicolas Iooss <nicolas.iooss@m4x.org>
To: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: SElinux list <selinux@vger.kernel.org>
Subject: Re: [PATCH libselinux 2/2] libselinux/src/Makefile: do not use PYCEXT, and rely on the installed file name
Date: Thu, 31 Oct 2019 18:40:21 +0100	[thread overview]
Message-ID: <CAJfZ7=koMBuaskafoDn2JR18a_FDLCZ3DGjKZZVRkwXRdDmyAg@mail.gmail.com> (raw)
In-Reply-To: <20191025134304.12666-2-thomas.petazzoni@bootlin.com>

On Fri, Oct 25, 2019 at 3:43 PM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> PYCEXT is computed by asking the Python intrepreter what is the
> file extension used for native Python modules.
>
> Unfortunately, when cross-compiling, the host Python doesn't give the
> proper result: it gives the result matching the build machine, and not
> the target machine. Due to this, the symlink has an incorrect name,
> and doesn't point to the .so file that was actually built/installed.
>
> To address this and keep things simple, this patch just changes the ln
> invocation to rely on the name of the _selinux*.so Python module that
> was installed.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

Hi,
Thanks for your patch. At first, I did not like forcing the extension
to ".so", because other operating systems use different extensions,
but in fact this point is not really an issue because libselinux and
libsemanage are very specific to Linux (contrary to libsepol, that may
be compiled for MacOS for example in order to analyze a policy there).

Anyway, I do not like using a wildcard pattern in the Makefile to
match the produced file. I wanted to reproduce your issue by
cross-compiling the python extension with "make
CC=aarch64-linux-gnu-gcc DESTDIR=/tmp/selinux install-pywrap", but
this fails with the following messages:

creating build
creating build/temp.linux-x86_64-3.7
aarch64-linux-gnu-gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g
-fwrapv -O3 -Wall -march=x86-64 -mtune=generic -O3 -pipe -fno-plt
-march=x86-64 -mtune=generic -O3 -pipe -fno-plt -march=x86-64
-mtune=generic -O3 -pipe -fno-plt -O2 -Werror -Wall -Wextra
-Wmissing-format-attribute -Wmissing-noreturn -Wpointer-arith -Wshadow
-Wstrict-prototypes -Wundef -Wunused -Wwrite-strings -Wformat=2
-Wno-padded -Wno-cast-align -Wno-cast-qual -Wno-conversion
-Wno-missing-prototypes -Wno-packed -Wno-switch-enum
-Wno-variadic-macros -Wno-vla -ftrapv -Wno-clobbered
-Wno-maybe-uninitialized -Wno-uninitialized -Wno-unused-result
-I/tmp/selinux/usr/include -I../include -D_GNU_SOURCE
-DNO_ANDROID_BACKEND -Wno-shadow -Wno-cast-function-type
-Wno-stringop-truncation -fPIC -I../include -I/tmp/selinux/usr/include
-I/usr/include/python3.7m -c selinuxswig_python_wrap.c -o
build/temp.linux-x86_64-3.7/selinuxswig_python_wrap.o
Assembler messages:
Error: unknown architecture `x86-64'

I am not used to cross-compile native Python extensions so I might
miss something obvious. What tools/configuration are you using in
order to make setup.py cross-compile correctly? It would be great if
the configuration you are using allows getting the produced file
extension. And this information would also help creating a
configuration for Travis-CI in order to check whether
cross-compilation works.

Thanks,
Nicolas

> ---
>  libselinux/src/Makefile | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
> index dc675a49..3fc535d4 100644
> --- a/libselinux/src/Makefile
> +++ b/libselinux/src/Makefile
> @@ -15,7 +15,6 @@ INCLUDEDIR ?= $(PREFIX)/include
>  PYINC ?= $(shell $(PKG_CONFIG) --cflags $(PYPREFIX))
>  PYLIBS ?= $(shell $(PKG_CONFIG) --libs $(PYPREFIX))
>  PYTHONLIBDIR ?= $(shell $(PYTHON) -c "from distutils.sysconfig import *; print(get_python_lib(plat_specific=1, prefix='$(PREFIX)'))")
> -PYCEXT ?= $(shell $(PYTHON) -c 'import imp;print([s for s,m,t in imp.get_suffixes() if t == imp.C_EXTENSION][0])')
>  RUBYINC ?= $(shell $(RUBY) -e 'puts "-I" + RbConfig::CONFIG["rubyarchhdrdir"] + " -I" + RbConfig::CONFIG["rubyhdrdir"]')
>  RUBYLIBS ?= $(shell $(RUBY) -e 'puts "-L" + RbConfig::CONFIG["libdir"] + " -L" + RbConfig::CONFIG["archlibdir"] + " " + RbConfig::CONFIG["LIBRUBYARG_SHARED"]')
>  RUBYINSTALL ?= $(shell $(RUBY) -e 'puts RbConfig::CONFIG["vendorarchdir"]')
> @@ -175,7 +174,7 @@ install: all
>  install-pywrap: pywrap
>         $(PYTHON) setup.py install --prefix=$(PREFIX) `test -n "$(DESTDIR)" && echo --root $(DESTDIR)`
>         install -m 644 $(SWIGPYOUT) $(DESTDIR)$(PYTHONLIBDIR)/selinux/__init__.py
> -       cd $(DESTDIR)$(PYTHONLIBDIR) && ln -sf selinux/_selinux$(PYCEXT) _selinux$(PYCEXT)
> +       cd $(DESTDIR)$(PYTHONLIBDIR) && ln -sf selinux/_selinux*.so .
>
>  install-rubywrap: rubywrap
>         test -d $(DESTDIR)$(RUBYINSTALL) || install -m 755 -d $(DESTDIR)$(RUBYINSTALL)
> --
> 2.21.0
>


  reply	other threads:[~2019-10-31 17:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-25 13:43 [PATCH libselinux 1/2] libselinux/src/Makefile: don't use ln --relative option Thomas Petazzoni
2019-10-25 13:43 ` [PATCH libselinux 2/2] libselinux/src/Makefile: do not use PYCEXT, and rely on the installed file name Thomas Petazzoni
2019-10-31 17:40   ` Nicolas Iooss [this message]
2019-10-28 17:06 ` [PATCH libselinux 1/2] libselinux/src/Makefile: don't use ln --relative option Stephen Smalley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJfZ7=koMBuaskafoDn2JR18a_FDLCZ3DGjKZZVRkwXRdDmyAg@mail.gmail.com' \
    --to=nicolas.iooss@m4x.org \
    --cc=selinux@vger.kernel.org \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).