Hi Andreas,
On Mon, 27 Jan 2014 19:46:03 +0100, Andreas Färber afaerber@suse.de wrote:
Hello,
Am 27.01.2014 15:24, schrieb Wolfgang Denk:
In message 1390798091-24747-1-git-send-email-afaerber@suse.de you wrote:
Avoids "could not find output section .gnu.hash" ld.bfd errors on openSUSE.
Cc: Albert Aribaud albert.u.boot@aribaud.net Cc: Tom Rini trini@ti.com Signed-off-by: Andreas Färber afaerber@suse.de
More changes like this may be needed, but these I compile-tested with v2014.01 (regression from v2013.10). colibri_t20_iris was runtime-tested. GCC 4.8.2 r206511, binutils 2.24
arch/arm/cpu/u-boot.lds | 1 + board/ti/am335x/u-boot.lds | 1 + 2 files changed, 2 insertions(+)
Is this an ARM specific issue, or other architectures affected as well?
I figured out that the section was apparently not caught by the .gnu* wildcard and this patch fixed our build for the following ARM configs:
am335x_evm arndale colibri_t20_iris cubieboard highbank hyundai_a7hd mele_a1000 mx53loco omap3_beagle omap4_panda paz00 rpi_b
My guess was that this could be related to the arm-only commit: http://git.denx.de/?p=u-boot.git;a=commit;h=47ed5dd031d7d2c587e6afd386e79cce... (which touches on a few more .lds files than mine)
But I see nothing ARM-specific in .gnu.hash sections, so other architectures might in theory be affected as well. Cf. http://sourceware.org/ml/binutils/2006-10/msg00377.html
I did read your post for ELDK pointing someone to an FAQ entry on not using gcc-specific flags with ld, but for one I did not spot such a thing in the ld command line, and for another our toolchain did not change and v2013.10 builds succeed whereas v2014.01 builds failed without the patch. I could try to git-bisect the offending change if necessary.
Using gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu7), I cannot see any issues on these boards:
am335x_evm colibri_t20_iris highbank mx53loco omap3_beagle omap4_panda paz00 rpi_b
On arndale, issues are due to warnings unrelated to linking.
Cubieboard, hyundai_a7hd, mele_a1000 are not in mainline AFAICT (but I'd like to see mele_a1000 in, as this might mean mele_a1000g could follow. :) )
Can you point me to the toolchain you are using, and if you are not building mainline code, can you make this code available to me somehow?
Best regards,
Andreas
Amicalement,