Patchwork [v2] Makefile: Symlink lib32 to lib for MIPS64/n32

login
register
mail settings
Submitter Markos Chandras
Date July 3, 2013, 1:06 p.m.
Message ID <1372856816-12493-1-git-send-email-markos.chandras@gmail.com>
Download mbox | patch
Permalink /patch/256630/
State Rejected
Headers show

Comments

Markos Chandras - July 3, 2013, 1:06 p.m.
From: Markos Chandras <markos.chandras@imgtec.com>

gcc hardcodes the uClibc interpreter for MIPS64/n32 as follows:
(gcc-4.7.3, gcc/config/mips/linux64.h):
define UCLIBC_DYNAMIC_LINKERN32 "/lib32/ld-uClibc.so.0"

However, buildroot always creates the $(TARGET_DIR)/lib,
$(TARGET_DIR)/usr/lib, $(STAGING_DIR)/lib and
$(STAGING_DIR)/usr/lib directories, therefore for consinstency
reasons, we create a lib32->lib symlink to fix the interpreter
problems for MIPS64/n32.

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
---
Changes since v1:
http://lists.busybox.net/pipermail/buildroot/2013-July/074586.html
- drop pushd/popd
- Create symlinks for the STAGING_DIR as well
---
 Makefile | 7 +++++++
 1 file changed, 7 insertions(+)
Markos Chandras - July 9, 2013, 10:26 a.m.
On 3 July 2013 14:06, Markos Chandras <markos.chandras@gmail.com> wrote:
> From: Markos Chandras <markos.chandras@imgtec.com>
>
> gcc hardcodes the uClibc interpreter for MIPS64/n32 as follows:
> (gcc-4.7.3, gcc/config/mips/linux64.h):
> define UCLIBC_DYNAMIC_LINKERN32 "/lib32/ld-uClibc.so.0"
>
> However, buildroot always creates the $(TARGET_DIR)/lib,
> $(TARGET_DIR)/usr/lib, $(STAGING_DIR)/lib and
> $(STAGING_DIR)/usr/lib directories, therefore for consinstency
> reasons, we create a lib32->lib symlink to fix the interpreter
> problems for MIPS64/n32.
>
> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
> ---
> Changes since v1:
> http://lists.busybox.net/pipermail/buildroot/2013-July/074586.html
> - drop pushd/popd
> - Create symlinks for the STAGING_DIR as well
> ---
>  Makefile | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index 509eab6..31c41e4 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -436,6 +436,13 @@ $(BUILD_DIR)/.root:
>                 --exclude .hg --exclude=CVS --exclude '*~' \
>                 $(TARGET_SKELETON)/ $(TARGET_DIR)/
>         cp support/misc/target-dir-warning.txt $(TARGET_DIR_WARNING_FILE)
> +ifeq ($(BR2_MIPS_NABI32),y)
> +       ln -sfn lib $(TARGET_DIR)/lib32
> +       ln -sfn lib $(TARGET_DIR)/usr/lib32
> +       ln -sfn lib $(STAGING_DIR)/lib32
> +       ln -sfn lib $(STAGING_DIR)/usr/lib32
> +
> +endif
>         touch $@
>
>  $(TARGET_DIR): $(BUILD_DIR)/.root
> --
> 1.8.2.1
>
>
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

Ping?

--
Regards,
Markos Chandras
Thomas De Schampheleire - July 11, 2013, 9:24 a.m.
Hi,

On Wed, Jul 3, 2013 at 3:06 PM, Markos Chandras
<markos.chandras@gmail.com> wrote:
> From: Markos Chandras <markos.chandras@imgtec.com>
>
> gcc hardcodes the uClibc interpreter for MIPS64/n32 as follows:
> (gcc-4.7.3, gcc/config/mips/linux64.h):
> define UCLIBC_DYNAMIC_LINKERN32 "/lib32/ld-uClibc.so.0"
>
> However, buildroot always creates the $(TARGET_DIR)/lib,
> $(TARGET_DIR)/usr/lib, $(STAGING_DIR)/lib and
> $(STAGING_DIR)/usr/lib directories, therefore for consinstency
> reasons, we create a lib32->lib symlink to fix the interpreter
> problems for MIPS64/n32.
>
> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
> ---
> Changes since v1:
> http://lists.busybox.net/pipermail/buildroot/2013-July/074586.html
> - drop pushd/popd
> - Create symlinks for the STAGING_DIR as well
> ---
>  Makefile | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index 509eab6..31c41e4 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -436,6 +436,13 @@ $(BUILD_DIR)/.root:
>                 --exclude .hg --exclude=CVS --exclude '*~' \
>                 $(TARGET_SKELETON)/ $(TARGET_DIR)/
>         cp support/misc/target-dir-warning.txt $(TARGET_DIR_WARNING_FILE)
> +ifeq ($(BR2_MIPS_NABI32),y)
> +       ln -sfn lib $(TARGET_DIR)/lib32
> +       ln -sfn lib $(TARGET_DIR)/usr/lib32
> +       ln -sfn lib $(STAGING_DIR)/lib32
> +       ln -sfn lib $(STAGING_DIR)/usr/lib32
> +
> +endif
>         touch $@
>
>  $(TARGET_DIR): $(BUILD_DIR)/.root

We are doing a similar thing from our post-build script, on a
Cavium-based MIPS64 n32 ABI, so I'm definitely in favor of this patch.

I'm not sure though if the $(BUILD_DIR)/.root rule is the best place
to put this, it seems a bit odd in my opinion.

Best regards,
Thomas
Thomas Petazzoni - July 11, 2013, 10:59 a.m.
Dear Thomas De Schampheleire,

On Thu, 11 Jul 2013 11:24:51 +0200, Thomas De Schampheleire wrote:

> We are doing a similar thing from our post-build script, on a
> Cavium-based MIPS64 n32 ABI, so I'm definitely in favor of this patch.
> 
> I'm not sure though if the $(BUILD_DIR)/.root rule is the best place
> to put this, it seems a bit odd in my opinion.

This thing is really toolchain related, so I believe it should be the
responsibility of the respective toolchain backends to take care of
this, whenever needed.

Thomas
Markos Chandras - July 11, 2013, 11:08 a.m.
On 11 July 2013 11:59, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Thu, 11 Jul 2013 11:24:51 +0200, Thomas De Schampheleire wrote:
>
>> We are doing a similar thing from our post-build script, on a
>> Cavium-based MIPS64 n32 ABI, so I'm definitely in favor of this patch.
>>
>> I'm not sure though if the $(BUILD_DIR)/.root rule is the best place
>> to put this, it seems a bit odd in my opinion.
>
> This thing is really toolchain related, so I believe it should be the
> responsibility of the respective toolchain backends to take care of
> this, whenever needed.
>

So would you prefer to move this code to package/gcc/gcc.mk ?

--
Regards,
Markos Chandras
Thomas De Schampheleire - July 11, 2013, 11:18 a.m.
On Thu, Jul 11, 2013 at 1:08 PM, Markos Chandras
<markos.chandras@gmail.com> wrote:
> On 11 July 2013 11:59, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Dear Thomas De Schampheleire,
>>
>> On Thu, 11 Jul 2013 11:24:51 +0200, Thomas De Schampheleire wrote:
>>
>>> We are doing a similar thing from our post-build script, on a
>>> Cavium-based MIPS64 n32 ABI, so I'm definitely in favor of this patch.
>>>
>>> I'm not sure though if the $(BUILD_DIR)/.root rule is the best place
>>> to put this, it seems a bit odd in my opinion.
>>
>> This thing is really toolchain related, so I believe it should be the
>> responsibility of the respective toolchain backends to take care of
>> this, whenever needed.
>>
>
> So would you prefer to move this code to package/gcc/gcc.mk ?
>

Are you experiencing this problem with a toolchain built via buildroot?
In my case, it is with an external toolchain, so package/gcc/gcc.mk
isn't used then.
Markos Chandras - July 11, 2013, 11:22 a.m.
On 11 July 2013 12:18, Thomas De Schampheleire
<patrickdepinguin+buildroot@gmail.com> wrote:
> On Thu, Jul 11, 2013 at 1:08 PM, Markos Chandras
> <markos.chandras@gmail.com> wrote:
>> On 11 July 2013 11:59, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com> wrote:
>>> Dear Thomas De Schampheleire,
>>>
>>> On Thu, 11 Jul 2013 11:24:51 +0200, Thomas De Schampheleire wrote:
>>>
>>>> We are doing a similar thing from our post-build script, on a
>>>> Cavium-based MIPS64 n32 ABI, so I'm definitely in favor of this patch.
>>>>
>>>> I'm not sure though if the $(BUILD_DIR)/.root rule is the best place
>>>> to put this, it seems a bit odd in my opinion.
>>>
>>> This thing is really toolchain related, so I believe it should be the
>>> responsibility of the respective toolchain backends to take care of
>>> this, whenever needed.
>>>
>>
>> So would you prefer to move this code to package/gcc/gcc.mk ?
>>
>
> Are you experiencing this problem with a toolchain built via buildroot?
> In my case, it is with an external toolchain, so package/gcc/gcc.mk
> isn't used then.

Yeah you are correct. This problem is not specific to buildroot
toolchains that's why I added
the fix in the root Makefile.

--
Regards,
Markos Chandras
Thomas Petazzoni - July 11, 2013, 1:40 p.m.
Dear Markos Chandras,

On Thu, 11 Jul 2013 12:22:32 +0100, Markos Chandras wrote:

> > Are you experiencing this problem with a toolchain built via buildroot?
> > In my case, it is with an external toolchain, so package/gcc/gcc.mk
> > isn't used then.
> 
> Yeah you are correct. This problem is not specific to buildroot
> toolchains that's why I added
> the fix in the root Makefile.

So, it would be needed for both the internal toolchain backend and the
external toolchain backend?

Thomas
Markos Chandras - July 11, 2013, 2 p.m.
On 11 July 2013 14:40, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Markos Chandras,
>
> On Thu, 11 Jul 2013 12:22:32 +0100, Markos Chandras wrote:
>
>> > Are you experiencing this problem with a toolchain built via buildroot?
>> > In my case, it is with an external toolchain, so package/gcc/gcc.mk
>> > isn't used then.
>>
>> Yeah you are correct. This problem is not specific to buildroot
>> toolchains that's why I added
>> the fix in the root Makefile.
>
> So, it would be needed for both the internal toolchain backend and the
> external toolchain backend?
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com

I presume it's needed for every uClibc based toolchain. It's
definitely needed by the buildroot toolchain which is the one I use.

--
Regards,
Markos Chandras
Thomas Petazzoni - July 11, 2013, 2:07 p.m.
Dear Markos Chandras,

On Thu, 11 Jul 2013 15:00:24 +0100, Markos Chandras wrote:

> I presume it's needed for every uClibc based toolchain. It's
> definitely needed by the buildroot toolchain which is the one I use.

But didn't you had gcc patches to make it use the correct patch for the
program interpreter? But yeah, for external toolchains, it's not
possible.

Thomas
Thomas De Schampheleire - July 11, 2013, 2:19 p.m.
On Thu, Jul 11, 2013 at 4:00 PM, Markos Chandras
<markos.chandras@gmail.com> wrote:
> On 11 July 2013 14:40, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Dear Markos Chandras,
>>
>> On Thu, 11 Jul 2013 12:22:32 +0100, Markos Chandras wrote:
>>
>>> > Are you experiencing this problem with a toolchain built via buildroot?
>>> > In my case, it is with an external toolchain, so package/gcc/gcc.mk
>>> > isn't used then.
>>>
>>> Yeah you are correct. This problem is not specific to buildroot
>>> toolchains that's why I added
>>> the fix in the root Makefile.
>>
>> So, it would be needed for both the internal toolchain backend and the
>> external toolchain backend?
>>
>
> I presume it's needed for every uClibc based toolchain. It's
> definitely needed by the buildroot toolchain which is the one I use.

It's not even uClibc-specific, same holds for glibc-based toolchains.
From gcc/config/mips/linux64.h:

#define GLIBC_DYNAMIC_LINKER32 "/lib/ld.so.1"
#define GLIBC_DYNAMIC_LINKER64 "/lib64/ld.so.1"
#define GLIBC_DYNAMIC_LINKERN32 "/lib32/ld.so.1"
#define UCLIBC_DYNAMIC_LINKERN32 "/lib32/ld-uClibc.so.0"
Markos Chandras - July 11, 2013, 2:30 p.m.
On 11 July 2013 15:07, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Markos Chandras,
>
> On Thu, 11 Jul 2013 15:00:24 +0100, Markos Chandras wrote:
>
>> I presume it's needed for every uClibc based toolchain. It's
>> definitely needed by the buildroot toolchain which is the one I use.
>
> But didn't you had gcc patches to make it use the correct patch for the
> program interpreter? But yeah, for external toolchains, it's not
> possible.
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com

I did? I don't remember that :/

--
Regards,
Markos Chandras
Markos Chandras - July 11, 2013, 2:31 p.m.
On 11 July 2013 15:19, Thomas De Schampheleire
<patrickdepinguin+buildroot@gmail.com> wrote:
> On Thu, Jul 11, 2013 at 4:00 PM, Markos Chandras
> <markos.chandras@gmail.com> wrote:
>> On 11 July 2013 14:40, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com> wrote:
>>> Dear Markos Chandras,
>>>
>>> On Thu, 11 Jul 2013 12:22:32 +0100, Markos Chandras wrote:
>>>
>>>> > Are you experiencing this problem with a toolchain built via buildroot?
>>>> > In my case, it is with an external toolchain, so package/gcc/gcc.mk
>>>> > isn't used then.
>>>>
>>>> Yeah you are correct. This problem is not specific to buildroot
>>>> toolchains that's why I added
>>>> the fix in the root Makefile.
>>>
>>> So, it would be needed for both the internal toolchain backend and the
>>> external toolchain backend?
>>>
>>
>> I presume it's needed for every uClibc based toolchain. It's
>> definitely needed by the buildroot toolchain which is the one I use.
>
> It's not even uClibc-specific, same holds for glibc-based toolchains.
> From gcc/config/mips/linux64.h:
>
> #define GLIBC_DYNAMIC_LINKER32 "/lib/ld.so.1"
> #define GLIBC_DYNAMIC_LINKER64 "/lib64/ld.so.1"
> #define GLIBC_DYNAMIC_LINKERN32 "/lib32/ld.so.1"
> #define UCLIBC_DYNAMIC_LINKERN32 "/lib32/ld-uClibc.so.0"

Oh right. Apologies for not checking the glibc case.

--
Regards,
Markos Chandras
Thomas Petazzoni - July 12, 2013, 8:10 a.m.
Dear Thomas De Schampheleire,

On Thu, 11 Jul 2013 16:19:31 +0200, Thomas De Schampheleire wrote:

> It's not even uClibc-specific, same holds for glibc-based toolchains.
> From gcc/config/mips/linux64.h:
> 
> #define GLIBC_DYNAMIC_LINKER32 "/lib/ld.so.1"
> #define GLIBC_DYNAMIC_LINKER64 "/lib64/ld.so.1"
> #define GLIBC_DYNAMIC_LINKERN32 "/lib32/ld.so.1"
> #define UCLIBC_DYNAMIC_LINKERN32 "/lib32/ld-uClibc.so.0"

Ok, I was mistaken by http://patchwork.ozlabs.org/patch/256596/. But
this patch is the one that makes uClibc actually match the program
interpreter path with the one used by gcc. So yeah, those symbolic
links are also needed.

Thomas
Markos Chandras - July 14, 2013, 10:07 p.m.
On 12 July 2013 09:10, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Thu, 11 Jul 2013 16:19:31 +0200, Thomas De Schampheleire wrote:
>
>> It's not even uClibc-specific, same holds for glibc-based toolchains.
>> From gcc/config/mips/linux64.h:
>>
>> #define GLIBC_DYNAMIC_LINKER32 "/lib/ld.so.1"
>> #define GLIBC_DYNAMIC_LINKER64 "/lib64/ld.so.1"
>> #define GLIBC_DYNAMIC_LINKERN32 "/lib32/ld.so.1"
>> #define UCLIBC_DYNAMIC_LINKERN32 "/lib32/ld-uClibc.so.0"
>
> Ok, I was mistaken by http://patchwork.ozlabs.org/patch/256596/. But
> this patch is the one that makes uClibc actually match the program
> interpreter path with the one used by gcc. So yeah, those symbolic
> links are also needed.
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com

Hi,

Is there anything else pending to be done for this patch in order to
be committed?

--
Regards,
Markos Chandras
Markos Chandras - July 20, 2013, 10:27 a.m.
On 14 July 2013 23:07, Markos Chandras <markos.chandras@gmail.com> wrote:
> On 12 July 2013 09:10, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Dear Thomas De Schampheleire,
>>
>> On Thu, 11 Jul 2013 16:19:31 +0200, Thomas De Schampheleire wrote:
>>
>>> It's not even uClibc-specific, same holds for glibc-based toolchains.
>>> From gcc/config/mips/linux64.h:
>>>
>>> #define GLIBC_DYNAMIC_LINKER32 "/lib/ld.so.1"
>>> #define GLIBC_DYNAMIC_LINKER64 "/lib64/ld.so.1"
>>> #define GLIBC_DYNAMIC_LINKERN32 "/lib32/ld.so.1"
>>> #define UCLIBC_DYNAMIC_LINKERN32 "/lib32/ld-uClibc.so.0"
>>
>> Ok, I was mistaken by http://patchwork.ozlabs.org/patch/256596/. But
>> this patch is the one that makes uClibc actually match the program
>> interpreter path with the one used by gcc. So yeah, those symbolic
>> links are also needed.
>>
>> Thomas
>> --
>> Thomas Petazzoni, Free Electrons
>> Kernel, drivers, real-time and embedded Linux
>> development, consulting, training and support.
>> http://free-electrons.com
>
> Hi,
>
> Is there anything else pending to be done for this patch in order to
> be committed?
>
> --
> Regards,
> Markos Chandras

Hi,

ping again? :)

--
Regards,
Markos Chandras

Patch

diff --git a/Makefile b/Makefile
index 509eab6..31c41e4 100644
--- a/Makefile
+++ b/Makefile
@@ -436,6 +436,13 @@  $(BUILD_DIR)/.root:
 		--exclude .hg --exclude=CVS --exclude '*~' \
 		$(TARGET_SKELETON)/ $(TARGET_DIR)/
 	cp support/misc/target-dir-warning.txt $(TARGET_DIR_WARNING_FILE)
+ifeq ($(BR2_MIPS_NABI32),y)
+	ln -sfn lib $(TARGET_DIR)/lib32
+	ln -sfn lib $(TARGET_DIR)/usr/lib32
+	ln -sfn lib $(STAGING_DIR)/lib32
+	ln -sfn lib $(STAGING_DIR)/usr/lib32
+
+endif
 	touch $@
 
 $(TARGET_DIR): $(BUILD_DIR)/.root