[U-Boot] How do I tell buildman to use a /specific/ toolchain?

Simon Glass sjg at chromium.org
Mon Mar 7 03:39:33 CET 2016


Hi Stephen,

On 4 October 2015 at 19:19, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 10/04/2015 10:38 AM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On 3 October 2015 at 20:20, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>> On 10/03/2015 08:30 AM, Simon Glass wrote:
>>>> Hi Stephen,
>>>>
>>>> On 2 October 2015 at 00:27, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>>> On 10/01/2015 04:59 PM, Simon Glass wrote:
>>>>>>
>>>>>> Hi Stephen,
>>>>>>
>>>>>> On Wednesday, 23 September 2015, Stephen Warren <swarren at wwwdotorg.org>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Simon,
>>>>>>>
>>>>>>> I have 3 different ARM toolchains installed into /usr/bin via distro
>>>>>>> packages. How do I tell buildman which of those to use?
>>>>>>>
>>>>>>> I had originally thought that ~/.buildman's [toolchain] section contained
>>>>>>> CROSS_COMPILE-like values, so I tried:
>>>>>>>
>>>>>>>> [toolchain]
>>>>>>>> root: /
>>>>>>>> arm0-not-installed: arm-none-gnueabi-
>>>>>>>> arm1: arm-none-eabi-
>>>>>>>> arm2: arm-linux-gnueabihf-
>>>>>>>> arm3: arm-linux-gnueabi-
>>>>>>>> arch64: aarch64-linux-gnu-
>>>>>>>>
>>>>>>>> [toolchain-alias]
>>>>>>>> arm: arm1
>>>>>>>> aarch64: aarch64
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> (I intended to change the "arm: arm1" line to point at arm1/2/3 based on
>>>>>>> which I wanted to use at a particular time).
>>>>>>>
>>>>>>> However, running "buildman --list-toolchains" and re-reading the docs
>>>>>>> shows me that the [toolchain] values are absolute directories that buildman
>>>>>>> searches for files named *-gcc:
>>>>>>>
>>>>>>>>     - scanning path 'arm-none-gnueabi-'
>>>>>>>>        - looking in 'arm-none-gnueabi-/.'
>>>>>>>>        - looking in 'arm-none-gnueabi-/bin'
>>>>>>>>        - looking in 'arm-none-gnueabi-/usr/bin'
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> If buildman finds multiple toolchains, there doesn't seem to be a way to
>>>>>>> tell it which one to use. Am I missing something?
>>>>>>>
>>>>>>> I suppose a solution wouuld be to move the compiler binaries into
>>>>>>> different separate directories, and only list one of those directories in
>>>>>>> ~/.buildman. However, I can't do that for distro-packaged toolchains (well,
>>>>>>> I suppose I could manually mv everything all over the place, but that's
>>>>>>> really fragile since it'd break any time the package got upgraded or removed
>>>>>>> and re-installed).
>>>>>>>
>>>>>>> I think it makes sense to add new syntax into ~/.buildman to specify
>>>>>>> "don't do automagical searching, just use this CROSS_COMPILE value that I
>>>>>>> say". Does that sound reasonable? Automagic stuff makes for great defaults,
>>>>>>> but if it can't be overridden, it sucks when you actually know what you
>>>>>>> want.
>>>>>>
>>>>>>
>>>>>> Yes I think it would be fine to add an option to use CROSS_COMPILE (of
>>>>>> course it would fail if you tried to build the board with the wrong
>>>>>> arch).
>>>>>
>>>>>
>>>>> I wasn't necessarily looking for buildman to pick up the CROSS_COMPILE
>>>>> environment variable, although that would be a simple solution for
>>>>> single-arch builds at least. My mention of CROSS_COMPILE immediately above
>>>>> was re: using values that are formatted in the same way as the CROSS_COMPILE
>>>>> environment variable would be, rather than directory names, in the config
>>>>> file. In other words, the example content I showed above.
>>>>>
>>>>>> The option other option at present is -G which lets you use multiple
>>>>>> .buildman files. You could have one of these for each toolchain.
>>>>>
>>>>>
>>>>> I don't think that gets me what I want. As far as I can tell, the buildman
>>>>> config file contains a list directories to search within, yet if I have 3
>>>>> toolchains in a single directory, there's no way to select which one I want
>>>>> to use, is there?
>>>>>
>>>>> In other words, a config file that contains:
>>>>>
>>>>> [toolchain]
>>>>> distro-packages: /usr/bin
>>>>>
>>>>> ... finds the following toolchains:
>>>>>
>>>>> [swarren at swarren-lx1 u-boot]$ ./tools/buildman/buildman \
>>>>>         --list-tool-chains
>>>>> Scanning for tool chains
>>>>>    - scanning path '/usr/bin'
>>>>>       - looking in '/usr/bin/.'
>>>>>          - found '/usr/bin/./arm-linux-gnueabi-gcc'
>>>>>          - found '/usr/bin/./arm-linux-gnueabihf-gcc'
>>>>>          - found '/usr/bin/./arm-none-eabi-gcc'
>>>>> (That's 3 AArch32 toolchains found)
>>>>>          - found '/usr/bin/./winegcc'
>>>>>          - found '/usr/bin/./aarch64-linux-gnu-gcc'
>>>>>          - found '/usr/bin/./gcc'
>>>>>          - found '/usr/bin/./c89-gcc'
>>>>>          - found '/usr/bin/./x86_64-linux-gnu-gcc'
>>>>>          - found '/usr/bin/./i586-mingw32msvc-gcc'
>>>>>          - found '/usr/bin/./c99-gcc'
>>>>>       - looking in '/usr/bin/bin'
>>>>>       - looking in '/usr/bin/usr/bin'
>>>>> Tool chain test:  OK
>>>>> Tool chain test:  OK
>>>>> Tool chain test:  OK
>>>>> Tool chain test:  OK
>>>>> Tool chain test:  OK
>>>>> Tool chain test:  OK
>>>>> Tool chain test:  OK
>>>>> Tool chain test:  OK
>>>>> Tool chain test:  OK
>>>>> Tool chain test:  OK
>>>>> List of available toolchains (7):
>>>>> aarch64   : /usr/bin/./aarch64-linux-gnu-gcc
>>>>> arm       : /usr/bin/./arm-linux-gnueabi-gcc
>>>>> (Buildman chose that one, and I think I have no control over that?)
>>>>> c89       : /usr/bin/./c89-gcc
>>>>> c99       : /usr/bin/./c99-gcc
>>>>> i586      : /usr/bin/./i586-mingw32msvc-gcc
>>>>> sandbox   : /usr/bin/./winegcc
>>>>> x86_64    : /usr/bin/./x86_64-linux-gnu-gcc
>>>>
>>>> I wonder if we need an option to specify the full path and avoid the search?
>>>>
>>>> Maybe [toolchain-prefix] ?
>>>
>>> Yes, that sounds like exactly what I was hoping for.
>>
>> OK - would you like to do a patch?
>
> I was hoping you could; I had looked into the toolchain selection
> algorithms in buildroot quite a while back and wasn't able to work out
> how to implement a feature like that.

I never did get to this. But I'll send a series soon which supports this.

Regards,
Simon


More information about the U-Boot mailing list