[U-Boot] ARM compiliation failing due to missing __lshrdi3 / EABI version conflict
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.
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?
Thanks, --jc
Dear "J.C. Wren",
In message 17434f2e0907261449o704a2544jfa3c2575dbd6d93d@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
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@denx.de wrote:
Dear "J.C. Wren",
In message 17434f2e0907261449o704a2544jfa3c2575dbd6d93d@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@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@spike.porcupine.org
participants (2)
-
J.C. Wren -
Wolfgang Denk