Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Charlie Jenkins <charlie@rivosinc.com>
To: Arnout Vandecappelle <arnout@mind.be>
Cc: buildroot@buildroot.org,
	Giulio Benetti <giulio.benetti@benettiengineering.com>,
	Romain Naour <romain.naour@gmail.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [Buildroot] [PATCH] toolchain-external: Fix external toolchains when BR2_ROOTFS_MERGED_USR
Date: Tue, 25 Mar 2025 19:57:15 -0700	[thread overview]
Message-ID: <Z-NtC3refUELEx5t@ghost> (raw)
In-Reply-To: <43c0f8e3-4e9f-4bf8-a0dd-0f39824c03a1@mind.be>

On Tue, Mar 25, 2025 at 10:47:12PM +0100, Arnout Vandecappelle wrote:
> 
> 
> On 11/03/2025 03:48, Charlie Jenkins wrote:
> > External toolchains like crosstool-ng place libraries at /lib.
> > When BR2_ROOTFS_MERGED_USR is enabled, these libraries were not being
> > copied into the target. This caused these toolchains to be unusable with
> > this option.
> > 
> > WHen BR2_ROOTFS_MERGED_USR is selected, copy the /lib and /lib64
> > directories into /usr/lib and /usr/lib64 respectively.
> 
>  This should already happen, because the lib -> usr/lib symlink should be
> created in staging dir before the toolchain sysroot is copied.
> 
>  But you reported in the other thread that the problem is actually with the
> symlink:
> 
> > $ ls -l ./output/host/riscv64-buildroot-linux-gnu/sysroot/usr/lib/libm.so
> > lrwxrwxrwx 1 charlie rvs 6 Mar  9 22:58 ./output/host/riscv64-buildroot-linux-gnu/sysroot/usr/lib/libm.so -> ../../
> 
>  So this looks liek the symlink creation is going wrong. That is done by the
> following code:
> 
> 	for link in $$(find $(STAGING_DIR) -type l); do \
> 		target=$$(readlink $${link}) ; \
> 		if [ "$${target}" == "$${target$(SHARP_SIGN)/}" ] ; then \
> 			continue ; \
> 		fi ; \
> 		relpath="$(call relpath_prefix,$${target$(SHARP_SIGN)/})" ; \
> 		echo "Fixing symlink $${link} from $${target} to
> $${relpath}$${target$(SHARP_SIGN)/}" ; \
> 		ln -sf $${relpath}$${target$(SHARP_SIGN)/} $${link} ; \
> 	done ; \
> 	relpath="$(call relpath_prefix,$${ARCH_LIB_DIR})" ; \
> 	if [ "$${relpath}" != "" ]; then \
> 		for i in $$(find -H $(STAGING_DIR)/$${ARCH_LIB_DIR}
> $(STAGING_DIR)/usr/$${ARCH_LIB_DIR} -type l -xtype l); do \
> 			LINKTARGET=`readlink $$i` ; \
> 			NEWLINKTARGET=$${LINKTARGET\#$$relpath} ; \
> 			ln -sf $${NEWLINKTARGET} $$i ; \
> 			$(call simplify_symlink,$$i,$(STAGING_DIR)) ; \
> 		done ; \
> 	fi ; \
> 
>  So I guess there is a symlink from usr/lib/libm.so to ../../lib/libm.so in
> the ct-ng toolchain, and that this doesn't get handled correctly by the code
> above. But honestly that code is not xxactly readable...

Are you suggesting that this is a problem with crosstool-ng and not with
Buildroot?

> 
> > 
> > Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
> > ---
> > I originally reported this issue here [1].
> > 
> > [1] https://lore.kernel.org/buildroot/Z86AGdrKHaUqgLVt@ghost/T/#t
> > ---
> >   toolchain/helpers.mk | 7 +++++++
> >   1 file changed, 7 insertions(+)
> > 
> > diff --git a/toolchain/helpers.mk b/toolchain/helpers.mk
> > index f3fdaaec07c5a01688da685c4d0fd4e2cb357b95..b565da8a3a8f12567920f14dd3b6a18e548da6c7 100644
> > --- a/toolchain/helpers.mk
> > +++ b/toolchain/helpers.mk
> > @@ -55,6 +55,9 @@ copy_toolchain_lib_root = \
> >   # corresponding architecture variants), and we don't want to import
> >   # them.
> >   #
> > +# Furthermore, when BR2_ROOTFS_MERGED_USR is enabled, the 'lib*' directories
> > +# need to be copied over to usr/'lib*'.
> > +#
> >   # If ARCH_LIB_DIR is not a singular directory component, e.g.
> >   # 'lib32/octeon2', then symbolic links in ARCH_LIB_DIR and
> >   # usr/ARCH_LIB_DIR may be broken because Buildroot will flatten the
> > @@ -109,6 +112,10 @@ copy_toolchain_sysroot = \
> >   	ARCH_SUBDIR="$(strip $3)"; \
> >   	ARCH_LIB_DIR="$(strip $4)" ; \
> >   	SUPPORT_LIB_DIR="$(strip $5)" ; \
> > +	if [ "$(BR2_ROOTFS_MERGED_USR)" == "y" ]; then \
> > +		rsync -au --chmod=u=rwX,go=rX $${ARCH_SYSROOT_DIR}/lib $(STAGING_DIR)/usr/lib 1>&2 ; \
> > +		rsync -au --chmod=u=rwX,go=rX $${ARCH_SYSROOT_DIR}/$${ARCH_LIB_DIR} $(STAGING_DIR)/usr/$${ARCH_LIB_DIR} 1>&2 ; \
> 
>  It looks suspicious to me that you copy both lib and ARCH_LIB_DIR - only
> one of them should be valid (or, usually, one is a symlink to the other).
> Also, ARCH_LIB_DIR is already handled in the loop below (in a slightly
> different way, because thanks to the trailing /, the lib -> usr/lib symlink
> is preserved).

Without both, the symlinks are not preserved. Getting rid of the
ARCH_LIB_DIR statement here results in the symlink being garbage:

./host/riscv64-buildroot-linux-gnu/sysroot/usr/lib/libm.so -> ../../

- Charlie

> 
>  Regards,
>  Arnout
> 
> > +	fi ; \
> >   	for i in etc $${ARCH_LIB_DIR} sbin usr usr/$${ARCH_LIB_DIR}; do \
> >   		if [ ! -d $${ARCH_SYSROOT_DIR}/$$i ] ; then \
> >   			continue ; \
> > 
> > ---
> > base-commit: 4809690d42f9b395ccb76ee7583c199fdd8d42c5
> > change-id: 20250310-fix_external_toolchains-d1b8c4da0be8
> 
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2025-03-26  2:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-11  2:48 [Buildroot] [PATCH] toolchain-external: Fix external toolchains when BR2_ROOTFS_MERGED_USR Charlie Jenkins
2025-03-25 21:47 ` Arnout Vandecappelle via buildroot
2025-03-26  2:57   ` Charlie Jenkins [this message]
2025-03-26  8:01     ` Arnout Vandecappelle via buildroot
2025-03-27  7:33       ` Charlie Jenkins

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=Z-NtC3refUELEx5t@ghost \
    --to=charlie@rivosinc.com \
    --cc=arnout@mind.be \
    --cc=buildroot@buildroot.org \
    --cc=giulio.benetti@benettiengineering.com \
    --cc=romain.naour@gmail.com \
    --cc=thomas.petazzoni@bootlin.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