From mboxrd@z Thu Jan  1 00:00:00 1970
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
Date: Mon, 14 Oct 2013 19:06:33 +0200
Subject: [U-Boot] [PATCH] Makefile: Introduce ARCH_PLATFORM_LIBGCC
 variable
In-Reply-To: <20131014151637.GA5843@oliver-linux>
References: <1381522383-25070-1-git-send-email-trini@ti.com>
	<20131012094333.422274df@lilith>
	<20131014151637.GA5843@oliver-linux>
Message-ID: <20131014190633.0284379e@lilith>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Tom,

On Mon, 14 Oct 2013 11:16:37 -0400, Tom Rini <trini@ti.com> wrote:

> On Sat, Oct 12, 2013 at 09:43:33AM +0200, Albert ARIBAUD wrote:
> > Hi Tom,
> > 
> > On Fri, 11 Oct 2013 16:13:03 -0400, Tom Rini <trini@ti.com> wrote:
> > 
> > > In some cases, such as arm multi-lib hardfloat (hf) toolchains, we will
> > > have multiple libgcc.a's available, and the arch needs to provide
> > > additional logic to determine the right file to use
> > > (-print-libgcc-file-name contains no CFLAG parsing logic).
> > > 
> > > Cc: Albert Aribaud <albert.u.boot@aribaud.net>
> > > Signed-off-by: Tom Rini <trini@ti.com>
> > > ---
> > >  Makefile           |    4 ++++
> > >  arch/arm/config.mk |   11 +++++++++++
> > >  2 files changed, 15 insertions(+)
> > > 
> > > diff --git a/Makefile b/Makefile
> > > index b09bfcc..13b396f 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -357,8 +357,12 @@ else
> > >  PLATFORM_LIBGCC = -L $(USE_PRIVATE_LIBGCC) -lgcc
> > >  endif
> > >  else
> > > +ifneq ("$(ARCH_PLATFORM_LIBGCC)","")
> > > +PLATFORM_LIBGCC := -L $(shell dirname $(ARCH_PLATFORM_LIBGCC)) -lgcc
> > > +else
> > >  PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc
> > >  endif
> > > +endif
> > >  PLATFORM_LIBS += $(PLATFORM_LIBGCC)
> > >  export PLATFORM_LIBS
> > >  
> > > diff --git a/arch/arm/config.mk b/arch/arm/config.mk
> > > index d0cf43f..e1d0dec 100644
> > > --- a/arch/arm/config.mk
> > > +++ b/arch/arm/config.mk
> > > @@ -19,6 +19,17 @@ LDFLAGS_FINAL += --gc-sections
> > >  PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \
> > >                       -fno-common -ffixed-r9 -msoft-float
> > >  
> > > +#
> > > +# When we use a hardfp toolchain if there are both 'libgcc.a' (hardfp) and
> > > +# 'arm-linux-gnueabi/libgcc.a' (softfp) we need to use the latter.  We
> > > +# cannot always build with a hardfp-only toolchain.
> > 
> > What does this last sentence mean exactly?
> 
> What it says.  If a hardfp only toolchain is used certain targets shall
> not link.  I had Marek confirm this as well.  I don't have the exact
> logs handy, but today there's a few targets that will fail, and the nand
> flash patchset introduces another because we enforce -msoft-float on
> U-Boot, and rely on libgcc from the toolchain for certain functions
> (__udivdi3 for example).

I was wondering if the sentence meant this, or if it meant "there is no
way we can ensure that we'll always build with a hardfp-only
toolchain". 

Maybe the ambiguity would be lifted by saying "Building with a
hardfp-only toolchain will fail [for some targets]"?

> I don't know how you weren't making this fail on ELDK 5.x armv7a-fp, but
> I was and the Linaro 2013.03 toolchain also will show this problem.
> Once I push the nand PR (shortly), building for am3517_crane for example
> will fail without this patch.

That may be because I have several toolchains installed, one of which
is in the standard path (/usr/bin, /usr/lib, etc).

Amicalement,
-- 
Albert.