[PATCH libselinux 1/2] libselinux/src/Makefile: don't use ln --relative option

[PATCH libselinux 1/2] libselinux/src/Makefile: don't use ln --relative option

[Thomas Petazzoni]

The ln --relative option is not available in fairly old versions of
ln, which are still in use in older Linux distributions.

Since the two use of ln --relative can very trivially be implemented
differently in libselinux/src/Makefile, let's do so.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
 libselinux/src/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
index 2b1696a0..dc675a49 100644
--- a/libselinux/src/Makefile
+++ b/libselinux/src/Makefile
@@ -170,12 +170,12 @@ install: all
 	install -m 755 $(LIBSO) $(DESTDIR)$(SHLIBDIR)
 	test -d $(DESTDIR)$(LIBDIR)/pkgconfig || install -m 755 -d $(DESTDIR)$(LIBDIR)/pkgconfig
 	install -m 644 $(LIBPC) $(DESTDIR)$(LIBDIR)/pkgconfig
-	ln -sf --relative $(DESTDIR)$(SHLIBDIR)/$(LIBSO) $(DESTDIR)$(LIBDIR)/$(TARGET)
+	cd $(DESTDIR)$(SHLIBDIR) && ln -sf $(LIBSO) $(TARGET)
 
 install-pywrap: pywrap
 	$(PYTHON) setup.py install --prefix=$(PREFIX) `test -n "$(DESTDIR)" && echo --root $(DESTDIR)`
 	install -m 644 $(SWIGPYOUT) $(DESTDIR)$(PYTHONLIBDIR)/selinux/__init__.py
-	ln -sf --relative $(DESTDIR)$(PYTHONLIBDIR)/selinux/_selinux$(PYCEXT) $(DESTDIR)$(PYTHONLIBDIR)/_selinux$(PYCEXT)
+	cd $(DESTDIR)$(PYTHONLIBDIR) && ln -sf selinux/_selinux$(PYCEXT) _selinux$(PYCEXT)
 
 install-rubywrap: rubywrap
 	test -d $(DESTDIR)$(RUBYINSTALL) || install -m 755 -d $(DESTDIR)$(RUBYINSTALL) 
-- 
2.21.0

[PATCH libselinux 2/2] libselinux/src/Makefile: do not use PYCEXT, and rely on the installed file name

[Thomas Petazzoni]

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>
---
 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

Re: [PATCH libselinux 1/2] libselinux/src/Makefile: don't use ln --relative option

[Stephen Smalley]

On 10/25/19 9:43 AM, Thomas Petazzoni wrote:
> The ln --relative option is not available in fairly old versions of
> ln, which are still in use in older Linux distributions.
> 
> Since the two use of ln --relative can very trivially be implemented
> differently in libselinux/src/Makefile, let's do so.

This changes where the libselinux.so symlink is created (from LIBDIR to 
SHLIBDIR), and yields a broken build for make DESTDIR=~/obj install.  As 
a result, the travis build breaks.

> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> ---
>   libselinux/src/Makefile | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
> index 2b1696a0..dc675a49 100644
> --- a/libselinux/src/Makefile
> +++ b/libselinux/src/Makefile
> @@ -170,12 +170,12 @@ install: all
>   	install -m 755 $(LIBSO) $(DESTDIR)$(SHLIBDIR)
>   	test -d $(DESTDIR)$(LIBDIR)/pkgconfig || install -m 755 -d $(DESTDIR)$(LIBDIR)/pkgconfig
>   	install -m 644 $(LIBPC) $(DESTDIR)$(LIBDIR)/pkgconfig
> -	ln -sf --relative $(DESTDIR)$(SHLIBDIR)/$(LIBSO) $(DESTDIR)$(LIBDIR)/$(TARGET)
> +	cd $(DESTDIR)$(SHLIBDIR) && ln -sf $(LIBSO) $(TARGET)
>   
>   install-pywrap: pywrap
>   	$(PYTHON) setup.py install --prefix=$(PREFIX) `test -n "$(DESTDIR)" && echo --root $(DESTDIR)`
>   	install -m 644 $(SWIGPYOUT) $(DESTDIR)$(PYTHONLIBDIR)/selinux/__init__.py
> -	ln -sf --relative $(DESTDIR)$(PYTHONLIBDIR)/selinux/_selinux$(PYCEXT) $(DESTDIR)$(PYTHONLIBDIR)/_selinux$(PYCEXT)
> +	cd $(DESTDIR)$(PYTHONLIBDIR) && ln -sf selinux/_selinux$(PYCEXT) _selinux$(PYCEXT)
>   
>   install-rubywrap: rubywrap
>   	test -d $(DESTDIR)$(RUBYINSTALL) || install -m 755 -d $(DESTDIR)$(RUBYINSTALL)
> 

Re: [PATCH libselinux 2/2] libselinux/src/Makefile: do not use PYCEXT, and rely on the installed file name

[Nicolas Iooss]

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
>