Makefile: Symlink lib32 to lib for MIPS64/n32

From: Markos Chandras <[email protected]>

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 <[email protected]>

---
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(+)

Makefile +7 -1

index 509eab6..31c41e4 100644
@@ -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 at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

From: Markos Chandras <[email protected]>

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 <[email protected]>

---
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(+)

Makefile +0 -0

index 509eab6..31c41e4 100644
@@ -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)

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.

Dear Thomas De Schampheleire,

Quoted 3 lines · Thomas De Schampheleire

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.

Quoted 2 lines

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.

Quoted 10 lines · Thomas Petazzoni

Dear Thomas De Schampheleire,

Quoted 5 lines · Thomas De Schampheleire

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.

Quoted 4 lines

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 ?

Quoted 17 lines · Markos Chandras

Quoted 14 lines · Thomas Petazzoni

Dear Thomas De Schampheleire,

Quoted 5 lines · Thomas De Schampheleire

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.

Quoted 2 lines

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.

Quoted 3 lines

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.

Dear Markos Chandras,

Quoted 7 lines · Markos Chandras

Quoted 3 lines

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.

Dear Markos Chandras,

Quoted 2 lines · Markos Chandras

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

Quoted 12 lines · Thomas Petazzoni

Dear Markos Chandras,

Quoted 7 lines · Markos Chandras

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 14 lines · Markos Chandras

Quoted 12 lines · Thomas Petazzoni

Dear Markos Chandras,

Quoted 7 lines · Markos Chandras

Quoted 3 lines

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.

Quoted 6 lines

Quoted 3 lines

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"

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"

Dear Thomas De Schampheleire,

Quoted 7 lines · Thomas De Schampheleire

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

Quoted 17 lines · Thomas Petazzoni

Dear Thomas De Schampheleire,

Quoted 7 lines · Thomas De Schampheleire

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.

Quoted 6 lines

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