linux-csky.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas De Schampheleire <patrickdepinguin@gmail.com>
To: Mao Han <han_mao@c-sky.com>
Cc: buildroot <buildroot@buildroot.org>,
	Qu Xianmiao <xianmiao_qu@c-sky.com>, Guo Ren <ren_guo@c-sky.com>,
	Mark Corbin <mark.corbin@embecosm.com>,
	linux-csky@vger.kernel.org,
	Chen Hongdeng <hongdeng_chen@c-sky.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [Buildroot] [PATCH 2/2] toolchain: Get ld.so name if available
Date: Wed, 5 Feb 2020 11:30:59 +0100	[thread overview]
Message-ID: <CAAXf6LUV+WOJc+x_yZtDQbEXq6yH4uD67mvMHZoRQGnj4nrsjg@mail.gmail.com> (raw)
In-Reply-To: <1577937441-18703-2-git-send-email-han_mao@c-sky.com>

Hi Mao Han,

El jue., 2 ene. 2020 a las 5:15, Mao Han (<han_mao@c-sky.com>) escribió:
>
> RISC-V multilib toolchain(github.com/riscv/riscv-gnu-toolchain.git) put
> multi ld.so with different ABI under sysroot/lib:
> sysroot/lib/ld-linux-riscv32-ilp32d.so.1
> sysroot/lib/ld-linux-riscv32-ilp32.so.1
> sysroot/lib/ld-linux-riscv64-lp64d.so.1
> sysroot/lib/ld-linux-riscv64-lp64.so.1
> Current buildroot script can't handle multi ld.so and report:
> >>> toolchain-external-custom  Copying external toolchain sysroot to staging...
> /bin/bash: line 0: [: too many arguments
> This patch try to get the exact name for ld.so and avoid multi ld.so check in
> the script.
>
> Signed-off-by: Qu Xianmiao <xianmiao_qu@c-sky.com>
> Signed-off-by: Chen Hongdeng <hongdeng_chen@c-sky.com>
> Signed-off-by: Guo Ren<ren_guo@c-sky.com>
> Signed-off-by: Mao Han <han_mao@c-sky.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> Cc: Mark Corbin <mark.corbin@embecosm.com>
> ---
>  toolchain/helpers.mk                                   | 10 ++++++++--
>  toolchain/toolchain-external/pkg-toolchain-external.mk |  3 ++-
>  2 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/toolchain/helpers.mk b/toolchain/helpers.mk
> index 03355f5..cc581fc 100644
> --- a/toolchain/helpers.mk
> +++ b/toolchain/helpers.mk
> @@ -104,6 +104,7 @@ copy_toolchain_sysroot = \
>         ARCH_SUBDIR="$(strip $3)"; \
>         ARCH_LIB_DIR="$(strip $4)" ; \
>         SUPPORT_LIB_DIR="$(strip $5)" ; \
> +       SPECIFIC_LD_NAME="$(strip $6)" ; \
>         for i in etc $${ARCH_LIB_DIR} sbin usr usr/$${ARCH_LIB_DIR}; do \
>                 if [ ! -d $${ARCH_SYSROOT_DIR}/$$i ] ; then \
>                         continue ; \
> @@ -136,8 +137,13 @@ copy_toolchain_sysroot = \
>                 done ; \
>         fi ; \
>         if [ ! -e $(STAGING_DIR)/lib/ld*.so.* ]; then \
> -               if [ -e $${ARCH_SYSROOT_DIR}/lib/ld*.so.* ]; then \
> -                       cp -a $${ARCH_SYSROOT_DIR}/lib/ld*.so.* $(STAGING_DIR)/lib/ ; \
> +               if [ "$${SPECIFIC_LD_NAME}" != "" ]; then \
> +                       LD_NAME=$${SPECIFIC_LD_NAME}; \
> +               else \
> +                       LD_NAME="ld*.so.*"; \
> +               fi; \

In addition to the comments posted previously by Yann E. Morin, I
wonder if there can actually be a case where SPECIFIC_LD_NAME is
empty. What I mean is: do we still need the wildcard-based approach if
we are using a more correct approach of actually checking the
interpreter via readelf?
Removing the wildcards would make the code a bit more clear. In this
case, the name 'SPECIFIC_LD_NAME' could perhaps be renamed to just
'LD_SO_FILENAME' or something.

Best regards,
Thomas

  parent reply	other threads:[~2020-02-05 10:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-02  3:57 [PATCH 1/2] package/toolchain-external: ensure ARCH_LIB_DIR exist Mao Han
2020-01-02  3:57 ` [PATCH 2/2] toolchain: Get ld.so name if available Mao Han
2020-01-26 15:31   ` [Buildroot] " Yann E. MORIN
2020-02-05 10:30   ` Thomas De Schampheleire [this message]
2020-01-10 10:57 ` [Buildroot] [PATCH 1/2] package/toolchain-external: ensure ARCH_LIB_DIR exist Thomas De Schampheleire
2020-01-10 11:15   ` Thomas Petazzoni
2020-01-13  3:34   ` Mao Han
2020-01-16  9:36     ` Thomas De Schampheleire
2020-01-17  2:35       ` Mao Han
2020-01-24 15:00         ` Thomas De Schampheleire
2020-01-26 15:34           ` Yann E. MORIN

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=CAAXf6LUV+WOJc+x_yZtDQbEXq6yH4uD67mvMHZoRQGnj4nrsjg@mail.gmail.com \
    --to=patrickdepinguin@gmail.com \
    --cc=buildroot@buildroot.org \
    --cc=han_mao@c-sky.com \
    --cc=hongdeng_chen@c-sky.com \
    --cc=linux-csky@vger.kernel.org \
    --cc=mark.corbin@embecosm.com \
    --cc=ren_guo@c-sky.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=xianmiao_qu@c-sky.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).