| Message ID | 1372856816-12493-1-git-send-email-markos.chandras@gmail.com |
|---|---|
| State | Rejected |
| Headers | show |
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
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
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
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
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.
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
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
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
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
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"
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
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
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
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
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
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