On Tue, 2021-10-19 at 14:49 -0400, Vivien Didelot wrote: > Hi all, > > I've, like many, run into the issue of toolchain detection for the > ti-sgx-ddk-km driver. I've noticed the ugly patch [1] getting edited to > add new toolchains like arm-oe-linux-gnueabi and arm-poky-linux-gnueabi. > > This is cumbersome because this step needs to be repeated for arbitrary > toolchain vendors, and it is error-prone since the toolchain added doesn't > explicitly mention the hardfp suffix expected by the driver, whereas > arm-*-gnueabihf is already matched. > > My point is that I believe the proper fix for this is to make sure the > toolchain generated by OpenEmbedded gets suffixed with "hf" when the hardfp > tune is enabled, so that this ugly patch can be dropped and toolchain > detection can work as expected. > > So far I've seen that the proper way to do this would be to set ABIEXTENSION > .= "hf" accordingly given the arch tune. The only problem I've encountered > so far is that the cross-canadian thingy [2] is zeroing the related variables > for some reasons. Hence I'm not sure how to configure this properly. > > [1] > http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-bsp/powervr-drivers/ti-sgx-ddk-km/0001-km-support-OpenEmbedded-hardfp-toolchain-w-o-gnueabi.patch > > [2] > http://cgit.openembedded.org/openembedded-core/tree/meta/classes/cross-canadian.bbclass#n64 > > Cc'ing Richard in case he has an input on the ugly ABI extension zeroing.
As Denys mentions, OE picked and used "OS" strings before the rest of the world did and we support custom vendor strings as you know. Changing the OS string has wide implications for other components as the strings are widely used, even in our own build directory paths. We have long since supposed using the vendor string as intended, to identify the vendor. I've seen several requests recently where we've been asked to match some other system's view of what these should look like. This effectively means OE being dictated to by other systems and I'm reluctant to do that, particularly as there are several of them and they don't all match, far from it. We'd match one until another comes along then we'd only be able to match one of them. I therefore think that either this recipe needs to be able to accept configuration of the toolchain and/or be able to validate the toolchain it is using as supporting hardfloat. As for cross-canadian zeroing out the ABI extension, this is because it has to support *all* targets so it will create one compiler and symlink into place all the variants the user might need. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14070): https://lists.yoctoproject.org/g/meta-ti/message/14070 Mute This Topic: https://lists.yoctoproject.org/mt/86447553/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
