[Buildroot] [PATCH v2] package/coreutils: allow building individual binaries

[Buildroot] [PATCH v2] package/coreutils: allow building individual binaries

[Markus Mayer]

We add configuration option BR2_PACKAGE_COREUTILS_INDIVIDUAL_BINARIES
so that coreutils can be built and installed as individual binaries.
It can be used if the target file system doesn't support symlinks or
symlinks are undesirable.

The approach is modelled after Busybox's similarly named configuration
option.

Signed-off-by: Markus Mayer <mmayer@broadcom.com>
---
 package/coreutils/Config.in    | 18 ++++++++++++++++++
 package/coreutils/coreutils.mk |  8 +++++++-
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/package/coreutils/Config.in b/package/coreutils/Config.in
index 11a6019e820f..a0a84c220a48 100644
--- a/package/coreutils/Config.in
+++ b/package/coreutils/Config.in
@@ -19,3 +19,21 @@ comment "coreutils needs a toolchain w/ wchar"
 	depends on BR2_USE_MMU
 	depends on !BR2_USE_WCHAR
 	depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS
+
+if BR2_PACKAGE_COREUTILS
+
+config BR2_PACKAGE_COREUTILS_INDIVIDUAL_BINARIES
+	bool "Individual binaries"
+	depends on !BR2_STATIC_LIBS
+	help
+	  By default (i.e. with this option disabled), coreutils is
+	  installed as a single binary (Busybox style) called
+	  /usr/bin/coreutils, and all core utilities are symbolic
+	  links to this binary.
+
+	  With this option enabled, each utility is a separate binary.
+
+comment "coreutils individual binaries need a toolchain w/ dynamic library"
+	depends on BR2_STATIC_LIBS
+
+endif
diff --git a/package/coreutils/coreutils.mk b/package/coreutils/coreutils.mk
index 3e8efbf04706..287b84873a05 100644
--- a/package/coreutils/coreutils.mk
+++ b/package/coreutils/coreutils.mk
@@ -14,8 +14,14 @@ COREUTILS_LICENSE_FILES = COPYING
 COREUTILS_AUTORECONF = YES
 COREUTILS_GETTEXTIZE = YES
 
-COREUTILS_CONF_OPTS = --disable-rpath --enable-single-binary=symlinks \
+COREUTILS_CONF_OPTS = \
+	--disable-rpath \
 	$(if $(BR2_TOOLCHAIN_USES_MUSL),--with-included-regex)
+
+ifeq ($(BR2_PACKAGE_COREUTILS_INDIVIDUAL_BINARIES),)
+COREUTILS_CONF_OPTS += --enable-single-binary=symlinks
+endif
+
 COREUTILS_CONF_ENV = ac_cv_c_restrict=no \
 	ac_cv_func_chown_works=yes \
 	ac_cv_func_euidaccess=no \
-- 
2.17.1

[Buildroot] [PATCH v2] package/coreutils: allow building individual binaries

[Peter Korsgaard]

>>>>> "Markus" == Markus Mayer <mmayer@broadcom.com> writes:

 > We add configuration option BR2_PACKAGE_COREUTILS_INDIVIDUAL_BINARIES
 > so that coreutils can be built and installed as individual binaries.
 > It can be used if the target file system doesn't support symlinks or
 > symlinks are undesirable.

Out of interest, what file system is that?

 > The approach is modelled after Busybox's similarly named configuration
 > option.

The use case for individual binaries for busybox is afaik mainly for
stuff like selinux, where you may want to have different policies for
the different applets.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH v2] package/coreutils: allow building individual binaries

[Markus Mayer]

On Wed, 10 Apr 2019 at 14:05, Peter Korsgaard <peter@korsgaard.com> wrote:
>
> >>>>> "Markus" == Markus Mayer <mmayer@broadcom.com> writes:
>
>  > We add configuration option BR2_PACKAGE_COREUTILS_INDIVIDUAL_BINARIES
>  > so that coreutils can be built and installed as individual binaries.
>  > It can be used if the target file system doesn't support symlinks or
>  > symlinks are undesirable.
>
> Out of interest, what file system is that?

VFAT -- yeah I know. At least only as a possible install medium not as
the rootfs.

>  > The approach is modelled after Busybox's similarly named configuration
>  > option.
>
> The use case for individual binaries for busybox is afaik mainly for
> stuff like selinux, where you may want to have different policies for
> the different applets.

That would certainly be another use case, which could also be listed
in the commit message.

Regards,
-Markus

[Buildroot] [PATCH v2] package/coreutils: allow building individual binaries

[Thomas Petazzoni]

Hello Markus,

On Wed, 10 Apr 2019 13:17:46 -0700
Markus Mayer <mmayer@broadcom.com> wrote:

> We add configuration option BR2_PACKAGE_COREUTILS_INDIVIDUAL_BINARIES
> so that coreutils can be built and installed as individual binaries.
> It can be used if the target file system doesn't support symlinks or
> symlinks are undesirable.
> 
> The approach is modelled after Busybox's similarly named configuration
> option.
> 
> Signed-off-by: Markus Mayer <mmayer@broadcom.com>

I tested this, with BR2_ROOTFS_MERGED_USR and got some broken symlinks
in /bin. I believe your patch is not sufficient. Indeed, it doesn't
take care of the following parts of coreutils.mk:

ifeq ($(BR2_ROOTFS_MERGED_USR),)
define COREUTILS_CLEANUP_BIN
        # some things go in /bin rather than /usr/bin
        $(foreach f,$(COREUTILS_BIN_PROGS), \
                rm -f $(TARGET_DIR)/usr/bin/$(f) && \
                ln -sf ../usr/bin/coreutils $(TARGET_DIR)/bin/$(f)
        )
endef
COREUTILS_POST_INSTALL_TARGET_HOOKS += COREUTILS_CLEANUP_BIN
endif

This probably needs to be changed to move applets from /usr/bin to /bin
rather than changing the symlinks.

define COREUTILS_CLEANUP
        # link for archaic shells
        ln -fs coreutils $(TARGET_DIR)/usr/bin/[
        # gnu thinks chroot is in bin, debian thinks it's in sbin
        rm -f $(TARGET_DIR)/usr/bin/chroot
        ln -sf ../bin/coreutils $(TARGET_DIR)/usr/sbin/chroot
endef

The symlink logic here also needs to be adjusted I guess.

Could you fix this and retest ?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v2] package/coreutils: allow building individual binaries

[Markus Mayer]

Hi Thomas,

It's been a while, but I had a chance to look at this again.

On Thu, 11 Apr 2019 at 09:56, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> On Wed, 10 Apr 2019 13:17:46 -0700
> Markus Mayer <mmayer@broadcom.com> wrote:
>
> > We add configuration option BR2_PACKAGE_COREUTILS_INDIVIDUAL_BINARIES
> > so that coreutils can be built and installed as individual binaries.
> > It can be used if the target file system doesn't support symlinks or
> > symlinks are undesirable.
> >
> > The approach is modelled after Busybox's similarly named configuration
> > option.
> >
> > Signed-off-by: Markus Mayer <mmayer@broadcom.com>
>
> I tested this, with BR2_ROOTFS_MERGED_USR and got some broken symlinks
> in /bin. I believe your patch is not sufficient. Indeed, it doesn't
> take care of the following parts of coreutils.mk:
>
> ifeq ($(BR2_ROOTFS_MERGED_USR),)
> define COREUTILS_CLEANUP_BIN
>         # some things go in /bin rather than /usr/bin
>         $(foreach f,$(COREUTILS_BIN_PROGS), \
>                 rm -f $(TARGET_DIR)/usr/bin/$(f) && \
>                 ln -sf ../usr/bin/coreutils $(TARGET_DIR)/bin/$(f)
>         )
> endef
> COREUTILS_POST_INSTALL_TARGET_HOOKS += COREUTILS_CLEANUP_BIN
> endif

You are saying above that you tried it *with* BR2_ROOTFS_MERGED_USR
and got broken links, but the above seems to be a problem if
BR2_ROOTFS_MERGED_USR is *disabled*, because the macro won't be
executed if it is enabled.

> This probably needs to be changed to move applets from /usr/bin to /bin
> rather than changing the symlinks.

I am not sure I am following. Why would we need to move applets from
/usr/bin to /bin? Shouldn't we let coreutils install its applets where
it sees fit? Or is the idea here that Buildroot wants to install
binaries in a different location than coreutils would? If the latter
is the case, yes, it would make sense to move the binaries rather than
creating symlinks.

> define COREUTILS_CLEANUP
>         # link for archaic shells
>         ln -fs coreutils $(TARGET_DIR)/usr/bin/[
>         # gnu thinks chroot is in bin, debian thinks it's in sbin
>         rm -f $(TARGET_DIR)/usr/bin/chroot
>         ln -sf ../bin/coreutils $(TARGET_DIR)/usr/sbin/chroot
> endef
>
> The symlink logic here also needs to be adjusted I guess.

Yes. Creating a symlink [ -> coreutils definitely won't work if we are
using individual binaries. It'll have to point to "test" instead. And
the solution for chroot would be similar to the symlinks above where
we move the binary instead of creating the link.

Does the proposed solution make sense?

Thanks,
-Markus




> Could you fix this and retest ?
>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com