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

[Wolfgang Denk]

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>