[U-Boot] ARM compiliation failing due to missing __lshrdi3 / EABI version conflict

[J.C. Wren]

The patches you just committed did the job, thank you.
And, yes, I DID read the thread to it's conclusion.  It wasn't helpful.  I
wasn't planning on becoming familiar with u-boot internals, but thanks to
TI, it's become a necessity.

--jc

On Sun, Jul 26, 2009 at 6:04 PM, Wolfgang Denk <wd at denx.de> wrote:

> Dear "J.C. Wren",
>
> In message <17434f2e0907261449o704a2544jfa3c2575dbd6d93d at mail.gmail.com>
> you wrote:
> >
> > I've pulled the most recent git version of u-boot, intending to compile
> it
> > for ARM.  Setting the target for davinci_dvevm and compiling caused the
> > linker to throw an error regarding EABI conflicts.  I removed libgcc from
> > the Makefile, and it appears that drivers/mtd/nand_base.c,
> > drivers/mtd_nand_oob.c and drivers/mtd/nand_bbt.c are looking for
> __lshrdi3.
> >
> > I found the thread originated by Jean-Christophe Plagniol-Villard (
> > http://www.mail-archive.com/u-boot@lists.denx.de/msg15910.html)
> regarding
> > some architectures having a libgcc dependency, and whether that should be
> > removed globally or on a per-build basis.
>
> Hm... why didn't you read the thread to it's (current) end?
>
> > I attempted to apply his patch, but the git repository seems to have seen
> > enough changes where it won't sync, and also I don't have an
> > arm_config.mkfile.  Perhaps this was a copy of
> > config.mk, but I still can't get it to sync on the patches.
> >
> > What my resolution path for this problem?
>
> Apply
>        [PATCH v2] Make linking against libgcc configurable
> and
>        [PATCH] arm: add _lshrdi3.S
>
> or wait for -rc1
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> A secure program has to be robust: it  must  be  able  to  deal  with
> conditions  that "can't happen", whether user input, program error or
> library/etc. This is basic damage  control.  Buffer  overflow  errors
> have nothing to do with security, but everything with stupidity.
>                 -- Wietse Venema in <5cnqm3$8r9 at spike.porcupine.org>
>