Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Romain Naour <romain.naour@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v11 3/4] toolchain-external: improve sysroot rsync if ARCH_LIB_DIR != lib/lib32/lib64
Date: Sun, 24 Jan 2016 20:59:37 +0100	[thread overview]
Message-ID: <56A52D29.9000307@gmail.com> (raw)
In-Reply-To: <1453317091-17676-3-git-send-email-patrickdepinguin@gmail.com>

Hi Thomas, All,

Le 20/01/2016 20:11, Thomas De Schampheleire a ?crit :
> From: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
> 
> The copy_toolchain_sysroot helper in toolchain/helpers.mk performs an
> rsync of various directories from the extracted external toolchain to the
> corresponding directory in staging.
> 
> The relevant (simplified) snippet is:
> 	for i in etc $${ARCH_LIB_DIR} sbin usr usr/$${ARCH_LIB_DIR}; do \
> 		rsync -au --chmod=u=rwX,go=rX --exclude 'usr/lib/locale' \
> 			--exclude '/lib/' --exclude '/lib32/' \
> 			--exclude '/lib64/' \
> 			$${ARCH_SYSROOT_DIR}/$$i/ $(STAGING_DIR)/$$i/ ; \
> 	done ; \
> 
> The exclusion logic of lib/lib32/lib64 has originally been added by commit
> 5628776c4a4d29d0715633ea463b64cc19e19c5a with the purpose of only copying
> the relevant usr/lib* directory from the toolchain to staging, instead of
> all. For example, if ARCH_LIB_DIR is 'lib64', then only usr/lib64 would be
> copied and usr/lib and usr/lib32 are ignored. It works by ignoring any
> lib/lib32/lib64 subdirectory on the rsync of 'usr' and then separately
> copying usr/{lib,lib32,lib64} as appropriate. (The exclusion rules only have
> impact on the files beneath the main source directory.)
> 
> However, ARCH_LIB_DIR can take other values than (lib, lib32, lib64), for
> example lib32-fp or lib64-fp (Octeon III toolchain with -march=octeon3). In
> the existing code, the rsync for 'usr' would then already copy these lib
> directories, and the next rsync for 'usr/$${ARCH_LIB_DIR}' does nothing.
> 
> By itself, this is not a very big problem: the staging directory simply has
> some extra directories. However, a subsequent patch will create a staging
> symlink from $${ARCH_LIB_DIR} to lib. The first rsync would then overwrite
> that symlink with the real directory usr/$${ARCH_LIB_DIR} from the
> toolchain, which is not correct.
> 
> Assuming the patch that creates the symlink ARCH_LIB_DIR->lib is applied,
> the original situation after 'make clean toolchain' with an
> ARCH_LIB_DIR=lib32-fp is:
> 
> $ ls -ld output/staging/{,usr/}lib* output/target/{usr/,}lib*
> drwxr-xr-x 2  4096 May 26  2015 output/staging/lib
> lrwxrwxrwx 1     3 Jan 20 13:47 output/staging/lib32 -> lib
> lrwxrwxrwx 1     3 Jan 20 13:47 output/staging/lib32-fp -> lib
> drwxr-xr-x 2  4096 Jan 20 13:47 output/staging/usr/lib
> lrwxrwxrwx 1     3 Jan 20 13:47 output/staging/usr/lib32 -> lib
> drwxr-xr-x 4  4096 May 26  2015 output/staging/usr/lib32-fp
> drwxr-xr-x 4  4096 May 26  2015 output/staging/usr/lib64-fp
> drwxr-xr-x 4  4096 May 26  2015 output/staging/usr/libexec
> drwxr-xr-x 3  4096 May 26  2015 output/staging/usr/libexec32
> drwxr-xr-x 3  4096 May 26  2015 output/staging/usr/libexec32-fp
> drwxr-xr-x 3  4096 May 26  2015 output/staging/usr/libexec64-fp
> drwxr-xr-x 2  4096 Jan 20 13:48 output/target/lib
> lrwxrwxrwx 1     3 Jan 20 13:47 output/target/lib32 -> lib
> lrwxrwxrwx 1     3 Jan 20 13:47 output/target/lib32-fp -> lib
> drwxr-xr-x 2  4096 Jan 20 13:48 output/target/usr/lib
> lrwxrwxrwx 1     3 Jan 20 13:47 output/target/usr/lib32 -> lib
> lrwxrwxrwx 1     3 Jan 20 13:47 output/target/usr/lib32-fp -> lib
> 
> Notice how usr/lib32-fp is not a symlink but a directory, and the presence
> of an unnecessary directory usr/lib64-fp.
> 
> This patch improves the rsync exclusion rules by excluding any lib*
> directory on the first rsync. As this would also exclude any
> libexec/libexec32/... directory, explicitly include them first (first match
> takes precedence). This (as is already the case today) results in more
> usr/libexec* directories than needed, but it is not touched by this patch.
> 
> With the fix applied, the situation becomes:
> 
> drwxr-xr-x 2 4096 May 26  2015 output/staging/lib
> lrwxrwxrwx 1    3 Jan 20 14:27 output/staging/lib32 -> lib
> lrwxrwxrwx 1    3 Jan 20 14:27 output/staging/lib32-fp -> lib
> drwxr-xr-x 4 4096 May 26  2015 output/staging/usr/lib
> lrwxrwxrwx 1    3 Jan 20 14:27 output/staging/usr/lib32 -> lib
> lrwxrwxrwx 1    3 Jan 20 14:27 output/staging/usr/lib32-fp -> lib
> drwxr-xr-x 4 4096 May 26  2015 output/staging/usr/libexec
> drwxr-xr-x 3 4096 May 26  2015 output/staging/usr/libexec32
> drwxr-xr-x 3 4096 May 26  2015 output/staging/usr/libexec32-fp
> drwxr-xr-x 3 4096 May 26  2015 output/staging/usr/libexec64-fp
> drwxr-xr-x 2 4096 Jan 20 14:27 output/target/lib
> lrwxrwxrwx 1    3 Jan 20 14:27 output/target/lib32 -> lib
> lrwxrwxrwx 1    3 Jan 20 14:27 output/target/lib32-fp -> lib
> drwxr-xr-x 2 4096 Jan 20 14:27 output/target/usr/lib
> lrwxrwxrwx 1    3 Jan 20 14:27 output/target/usr/lib32 -> lib
> lrwxrwxrwx 1    3 Jan 20 14:27 output/target/usr/lib32-fp -> lib
> 
> For cases where ARCH_LIB_DIR is one of lib, lib32 or lib64 this fix
> makes no difference, and likewise for internal toolchains.

Reviewed-by: Romain Naour <romain.naour@gmail.com>

> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
> Cc: Samuel Martin <s.martin49@gmail.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Arnout Vandecappelle <arnout@mind.be>
> 
> ---
> v11: unchanged
> v10: new patch
> 
>  toolchain/helpers.mk | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/toolchain/helpers.mk b/toolchain/helpers.mk
> index 906993d..02cc0bb 100644
> --- a/toolchain/helpers.mk
> +++ b/toolchain/helpers.mk
> @@ -154,8 +154,7 @@ copy_toolchain_sysroot = \
>  	for i in etc $${ARCH_LIB_DIR} sbin usr usr/$${ARCH_LIB_DIR}; do \
>  		if [ -d $${ARCH_SYSROOT_DIR}/$$i ] ; then \
>  			rsync -au --chmod=u=rwX,go=rX --exclude 'usr/lib/locale' \
> -				--exclude '/lib/' --exclude '/lib32/' \
> -				--exclude '/lib64/' \
> +				--include '/libexec*/' --exclude '/lib*/' \
>  				$${ARCH_SYSROOT_DIR}/$$i/ $(STAGING_DIR)/$$i/ ; \
>  		fi ; \
>  	done ; \
> 

  reply	other threads:[~2016-01-24 19:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-20 19:11 [Buildroot] [PATCH v11 1/4] skeleton: move LIB_SYMLINK definition from Makefile Thomas De Schampheleire
2016-01-20 19:11 ` [Buildroot] [PATCH v11 2/4] toolchain-external: don't exclude too much lib in sysroot rsync Thomas De Schampheleire
2016-01-24 19:58   ` Romain Naour
2016-01-20 19:11 ` [Buildroot] [PATCH v11 3/4] toolchain-external: improve sysroot rsync if ARCH_LIB_DIR != lib/lib32/lib64 Thomas De Schampheleire
2016-01-24 19:59   ` Romain Naour [this message]
2016-01-20 19:11 ` [Buildroot] [PATCH v11 4/4] toolchain-external: create symlink ARCH_LIB_DIR->lib Thomas De Schampheleire
2016-01-24 19:59   ` Romain Naour
2016-01-24 20:23     ` Thomas De Schampheleire
2016-01-24 20:42       ` Romain Naour
2016-01-20 20:55 ` [Buildroot] [PATCH v11 1/4] skeleton: move LIB_SYMLINK definition from Makefile Thomas Petazzoni

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=56A52D29.9000307@gmail.com \
    --to=romain.naour@gmail.com \
    --cc=buildroot@busybox.net \
    /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