From: Romain Naour <romain.naour@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v12 2/3] toolchain-external: improve sysroot rsync if ARCH_LIB_DIR != lib/lib32/lib64
Date: Sun, 31 Jan 2016 20:57:09 +0100 [thread overview]
Message-ID: <56AE6715.1000700@gmail.com> (raw)
In-Reply-To: <1453984366-12393-2-git-send-email-patrickdepinguin@gmail.com>
Hi Thomas,
Le 28/01/2016 13:32, 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.
>
> 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>
>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Best regards,
Romain
> ---
> v12: unchanged
> 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 ; \
>
next prev parent reply other threads:[~2016-01-31 19:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-28 12:32 [Buildroot] [PATCH v12 1/3] toolchain-external: don't exclude too much lib in sysroot rsync Thomas De Schampheleire
2016-01-28 12:32 ` [Buildroot] [PATCH v12 2/3] toolchain-external: improve sysroot rsync if ARCH_LIB_DIR != lib/lib32/lib64 Thomas De Schampheleire
2016-01-31 19:57 ` Romain Naour [this message]
2016-01-28 12:32 ` [Buildroot] [PATCH v12 3/3] toolchain-external: create symlink ARCH_LIB_DIR->lib Thomas De Schampheleire
2016-01-31 19:57 ` Romain Naour
2016-01-31 19:56 ` [Buildroot] [PATCH v12 1/3] toolchain-external: don't exclude too much lib in sysroot rsync Romain Naour
2016-02-01 13:26 ` 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=56AE6715.1000700@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