[Buildroot] [PATCH 1/1] toolchain-external: fix handling of ld.so

[Buildroot] [PATCH 1/1] toolchain-external: fix handling of ld.so

[Thomas De Schampheleire]

From: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>

Commit ba6bac138331cea449592f877e558f84176a70bf made a change in copying of
the dynamic loader, with the goal of reducing toolchain-specific fixups.
Any ld*.so file found in the toolchain's lib directory would be copied to
the staging/lib directory.

For the toolchains that previously needed fixup, this new behavior is fine.
The reason they needed fixup was that the normal copy action did not include
any dynamic loader.

However, for certain other toolchains this new behavior actually breaks
things: regardless of ARCH_LIB_DIR, which may be lib64 instead of lib, the
dynamic loader from lib is copied _over_ any previously correct dynamic
loader.

This has been witnessed with the CodeSourcery x86_64 and
CodeSourcery MIPS64 toolchains. In both cases, a 32-bit dynamic loader was
copied to staging/lib, while a 64-bit version was expected.

Fix the problem by only performing this explicit dynamic loader copy if no
dynamic loader is found in staging/lib.

Fixes http://autobuild.buildroot.net/results/8bf/8bffe54032aad9cc710a22411ef3bff4a2c93e55/

Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
---
 toolchain/helpers.mk | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/toolchain/helpers.mk b/toolchain/helpers.mk
index 5af38c6..90834f4 100644
--- a/toolchain/helpers.mk
+++ b/toolchain/helpers.mk
@@ -127,11 +127,13 @@ copy_toolchain_sysroot = \
 			$(call simplify_symlink,$$i,$(STAGING_DIR)) ; \
 		done ; \
 	fi ; \
-	if [ -e $${ARCH_SYSROOT_DIR}/lib/ld*.so ]; then \
-		cp -a $${ARCH_SYSROOT_DIR}/lib/ld*.so $(STAGING_DIR)/lib/ ; \
-	fi ; \
-	if [ -e $${ARCH_SYSROOT_DIR}/lib/ld*.so.* ]; then \
-		cp -a $${ARCH_SYSROOT_DIR}/lib/ld*.so.* $(STAGING_DIR)/lib/ ; \
+	if [ ! -e $(STAGING_DIR)/lib/ld*.so ] && [ ! -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/ ; \
+		fi ; \
+		if [ -e $${ARCH_SYSROOT_DIR}/lib/ld*.so.* ]; then \
+			cp -a $${ARCH_SYSROOT_DIR}/lib/ld*.so.* $(STAGING_DIR)/lib/ ; \
+		fi ; \
 	fi ; \
 	if [ `readlink -f $${SYSROOT_DIR}` != `readlink -f $${ARCH_SYSROOT_DIR}` ] ; then \
 		if [ ! -d $${ARCH_SYSROOT_DIR}/usr/include ] ; then \
-- 
2.10.2

[Buildroot] [PATCH 1/1] toolchain-external: fix handling of ld.so

[Thomas Petazzoni]

Hello,

On Thu,  6 Apr 2017 22:25:05 +0200, Thomas De Schampheleire wrote:
> From: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
> 
> Commit ba6bac138331cea449592f877e558f84176a70bf made a change in copying of
> the dynamic loader, with the goal of reducing toolchain-specific fixups.
> Any ld*.so file found in the toolchain's lib directory would be copied to
> the staging/lib directory.
> 
> For the toolchains that previously needed fixup, this new behavior is fine.
> The reason they needed fixup was that the normal copy action did not include
> any dynamic loader.
> 
> However, for certain other toolchains this new behavior actually breaks
> things: regardless of ARCH_LIB_DIR, which may be lib64 instead of lib, the
> dynamic loader from lib is copied _over_ any previously correct dynamic
> loader.
> 
> This has been witnessed with the CodeSourcery x86_64 and
> CodeSourcery MIPS64 toolchains. In both cases, a 32-bit dynamic loader was
> copied to staging/lib, while a 64-bit version was expected.
> 
> Fix the problem by only performing this explicit dynamic loader copy if no
> dynamic loader is found in staging/lib.
> 
> Fixes http://autobuild.buildroot.net/results/8bf/8bffe54032aad9cc710a22411ef3bff4a2c93e55/
> 
> Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
> ---
>  toolchain/helpers.mk | 12 +++++++-----
>  1 file changed, 7 insertions(+), 5 deletions(-)

Applied to master, thanks. It's adding more complexity to the existing
complexity, but oh well :/ Thanks for fixing it so quickly!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/1] toolchain-external: fix handling of ld.so

[Thomas De Schampheleire]

On Thu, Apr 6, 2017 at 10:34 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Thu,  6 Apr 2017 22:25:05 +0200, Thomas De Schampheleire wrote:
>> From: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
>>
>> Commit ba6bac138331cea449592f877e558f84176a70bf made a change in copying of
>> the dynamic loader, with the goal of reducing toolchain-specific fixups.
>> Any ld*.so file found in the toolchain's lib directory would be copied to
>> the staging/lib directory.
>>
>> For the toolchains that previously needed fixup, this new behavior is fine.
>> The reason they needed fixup was that the normal copy action did not include
>> any dynamic loader.
>>
>> However, for certain other toolchains this new behavior actually breaks
>> things: regardless of ARCH_LIB_DIR, which may be lib64 instead of lib, the
>> dynamic loader from lib is copied _over_ any previously correct dynamic
>> loader.
>>
>> This has been witnessed with the CodeSourcery x86_64 and
>> CodeSourcery MIPS64 toolchains. In both cases, a 32-bit dynamic loader was
>> copied to staging/lib, while a 64-bit version was expected.
>>
>> Fix the problem by only performing this explicit dynamic loader copy if no
>> dynamic loader is found in staging/lib.
>>
>> Fixes http://autobuild.buildroot.net/results/8bf/8bffe54032aad9cc710a22411ef3bff4a2c93e55/
>>
>> Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
>> ---
>>  toolchain/helpers.mk | 12 +++++++-----
>>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> Applied to master, thanks. It's adding more complexity to the existing
> complexity, but oh well :/ Thanks for fixing it so quickly!

If toolchain creators could just all do it the same way, then we
wouldn't have all this complexity :-X

/Thomas

[Buildroot] [PATCH 1/1] toolchain-external: fix handling of ld.so

[Thomas De Schampheleire]

On Apr 6, 2017 10:46 PM, "Thomas De Schampheleire" <
patrickdepinguin@gmail.com> wrote:

On Thu, Apr 6, 2017 at 10:34 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Thu,  6 Apr 2017 22:25:05 +0200, Thomas De Schampheleire wrote:
>> From: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
>>
>> Commit ba6bac138331cea449592f877e558f84176a70bf made a change in copying
of
>> the dynamic loader, with the goal of reducing toolchain-specific fixups.
>> Any ld*.so file found in the toolchain's lib directory would be copied to
>> the staging/lib directory.
>>
>> For the toolchains that previously needed fixup, this new behavior is
fine.
>> The reason they needed fixup was that the normal copy action did not
include
>> any dynamic loader.
>>
>> However, for certain other toolchains this new behavior actually breaks
>> things: regardless of ARCH_LIB_DIR, which may be lib64 instead of lib,
the
>> dynamic loader from lib is copied _over_ any previously correct dynamic
>> loader.
>>
>> This has been witnessed with the CodeSourcery x86_64 and
>> CodeSourcery MIPS64 toolchains. In both cases, a 32-bit dynamic loader
was
>> copied to staging/lib, while a 64-bit version was expected.
>>
>> Fix the problem by only performing this explicit dynamic loader copy if
no
>> dynamic loader is found in staging/lib.
>>
>> Fixes http://autobuild.buildroot.net/results/8bf/
8bffe54032aad9cc710a22411ef3bff4a2c93e55/
>>
>> Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com
>
>> ---
>>  toolchain/helpers.mk | 12 +++++++-----
>>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> Applied to master, thanks. It's adding more complexity to the existing
> complexity, but oh well :/ Thanks for fixing it so quickly!

If toolchain creators could just all do it the same way, then we
wouldn't have all this complexity :-X


Btw, in the x86_64 case, the problem was detected very early by
check-bin-arch, but in the mips case apparently not. I have not been able
to look into the code and won't be able to the coming days, but am I right
that this is the type of thing that check-bin-arch should find?

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170407/204b025a/attachment.html>

[Buildroot] [PATCH 1/1] toolchain-external: fix handling of ld.so

[Thomas Petazzoni]

Hello,

On Fri, 7 Apr 2017 10:16:31 +0200, Thomas De Schampheleire wrote:

> Btw, in the x86_64 case, the problem was detected very early by
> check-bin-arch, but in the mips case apparently not. I have not been able
> to look into the code and won't be able to the coming days, but am I right
> that this is the type of thing that check-bin-arch should find?

It depends if the ELF machine type was different or not between the two
sysroots. If they are different, then yes, it should have been detected.

(Again, please fix your e-mail client.)

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com