[Buildroot] [PATCHv3 08/14] configs: use new EABIhf option for beaglebone_defconfig
Peter Korsgaard
jacmet at uclibc.org
Tue Jul 16 13:39:19 UTC 2013
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni at free-electrons.com> writes:
Thomas> Dear Peter Korsgaard,
Thomas> On Tue, 16 Jul 2013 15:19:04 +0200, Peter Korsgaard wrote:
>> Did you test build this? I had a beaglebone derived config (but with
>> latest linaro), and u-boot failed to build with:
Thomas> Yes, I tried beaglebone_defconfig, which uses an internal toolchain...
Thomas> which would not exhibit this problem.
Ok, good. Then I'll commit it.
Thomas> Unfortunately, I'm not sure how to fix this particular problem. It's
Thomas> gcc that is too stupid to understand that -msoft-float appearing in the
Thomas> command line after -mfloat-abi=hard should take precedence over
Thomas> -mfloat-abi=hard. I believe we already had this case in the past, maybe
Thomas> not specifically with those options, but with other options.
Thomas> One solution I see to this is not very nice:
Thomas> if (gcc command line contains -msoft-float) {
Thomas> do not pass -mfloat-abi and -mfpu arguments
Thomas> }
You mean in the toolchain wrapper? Yddrk.
Thomas> The other solution is to simply not pass -mfloat-abi=hard, assuming the
Thomas> toolchain would by default generate such binaries, which should be the
Thomas> case because EABI and EABIhf are not compatible. However, we should
Thomas> still pass -mfloat-abi=soft/softfp as needed.
That could work, but also doesn't sound really nice. Presumably gcc
doesn't complain about -mfloat-abi=softfp -mfloat-abi=soft as those are
compatible.
Thomas> That makes me think that I should maybe add a check that ensures that
Thomas> the ABI selection (EABI/EABIhf) matches the one provided by the
Thomas> external toolchain (which is useful when custom external toolchains are
Thomas> used).
That would be a nice addition, yes.
--
Bye, Peter Korsgaard
More information about the buildroot
mailing list