Re: I like to add arm-none-eabi support to crosstool-ng

["Jasmin J." <jasmin at anw dot at>]

Hello Erico!

THX for answering!

> As I understand, a toolchain for the arm-none-eabi target could just
> be built from the regular gcc releases, and not only from the
> "embedded" gcc branch, couldn't it?
I am currently checking out the gcc-4_9-branch to compare them. But in most of
the tutorials for single chip micro-controllers the refer to the ARM version.
I don't want to run into problems due to a wrong compiler.

> This seems like a bug to me, I don't think you shouldn't be forced to
> use 5.1 or later by having enabled EXPERIMENTAL.
It is not EXPERIMENTAL which does cause the problem. It is CC_CUSTOM which
selects CC_GCC_latest and this always the latest GCC.

> Can you please re-test it with i.e. crosstool-ng 1.20 ? If it is a
> regression, please file an Issue in
In this version CC_GCC_latest is 4.9.x.
There should be a decoupling of CC_CUSTOM and CC_GCC_latest. In fact this
would mean to implement my suggestion 3.

> Is your intention to provide a configuration for arm-none-eabi only,
> or one that uses the "embedded" gcc branch?
I want to use the embedded branch (see above). But I will check the
differences.
At the end I plan to use some patches from the Miosix gcc version to build my
own tool version. But I like the idea to provide a configuration and maybe
extend crosstool-ng for the embedded arm-none-eabi toolchain. Because the
one provided on Launchpad
  https://launchpad.net/gcc-arm-embedded/4.9/4.9-2015-q2-update
require a lot more manual work, if you compile them out of the sources.

> For the latter, I believe that the best option would be to make
> crosstool-ng support remote repositories to be cloned and used for the
> build, similar to what Buildroot does with 'git' and 'svn' download
> methods for sources.
But this is the most effort intense variant. It is possible to implement this,
but would it be accepted?
I just checked buildroot-2015.05/support/download and this uses a temporary
file. But it can be changed to use a local directory.

On the other hand, my suggestion 3 would be much simpler you can achieve the
same. OK, you need to clone the repositories first manually, but crosstool-ng
is already able to use an external src directory.

> I too have missed this feature at least once, to distribute a
> configuration which uses a custom remote source in a format more
> portable than a path to a local directory (from my machine).
But the current implementation of CC_CUSTOM is not flexible anyway. So this is
currently not possible.

I plan to activate a new choice for the GCC version, when CC_CUSTOM is
selected and to remove the "select CC_GCC_latest" from CC_CUSTOM. And I will
remove the "depends on EXPERIMENTAL", because I don't see any reason to enable
a custom GCC only in experimental mode.
When I fix CC_CUSTOM that way, would it be accepted mainline?

BR
   Jasmin

***************************************************************************

On 08/28/2015 05:31 PM, Erico Nunes wrote:
> Hi Jasmin,
> 
> On Thu, Aug 27, 2015 at 8:44 PM, Jasmin J. <jasmin@anw.at> wrote:
>> Now I want to add the required configuration for arm-none-eabi. This GCC
>> version is developed on a branch
>>   https://gcc.gnu.org/svn/gcc/branches/ARM/embedded-4_9-branch/
> 
> As I understand, a toolchain for the arm-none-eabi target could just
> be built from the regular gcc releases, and not only from the
> "embedded" gcc branch, couldn't it?
> Then how to use specific gcc branches to build a toolchain is a
> different (and broader) question.
> 
> Doesn't the arm-unknown-eabi sample fit your requirements?
> 
>> To enable custom, it is required to enable EXPERIMENTAL. custom will enable
>> CC_GCC_latest and this will enable CC_GCC_5_1_or_later.
>> Because the ARM embedded GCC is a 4.9.x variant, it requires CLooG and this is
>> not built for GCC 5.1.x.
> 
> This seems like a bug to me, I don't think you shouldn't be forced to
> use 5.1 or later by having enabled EXPERIMENTAL.
> Can you please re-test it with i.e. crosstool-ng 1.20 ? If it is a
> regression, please file an Issue in
> https://github.com/crosstool-ng/crosstool-ng .
> 
>> There are now several possibilities.
>> 1)
>> i-  I can add a new configuration similar to GCC_SHOW_LINARO for the ARM
>>     embedded versions and pack my own arm-embedded GCC tarballs and post them
>>     on sourceforge.net or somewhere else (e.g. gcc-4.9-arm-224057.tar.bz2).
>> ii- Then I define the supported GCC version in the config (e.g.
>>     CC_GCC_V_arm_embedded_4_9_<svn-number> and then I need to add arm_embedded
>>     to 100-gcc.sh. And maybe more, which I will discover ;)
>>
>> 2)
>> i-  See above.
>> ii- I add an configuration, which opens a complete free gcc configuration with
>>     gcc version, tar-name, download location, and the GCC version flags (e.g.
>>     CC_GCC_4_9, CC_GCC_4_8, ... ).
>>
>> 3)
>> i-  I make a new configuration option when custom is selected to select the
>>     GCC version flag (e.g. CC_GCC_4_9, CC_GCC_4_8, ... ) and get rid of the
>>     hard coded CC_GCC_latest (which would be still the default).
> 
> Is your intention to provide a configuration for arm-none-eabi only,
> or one that uses the "embedded" gcc branch?
> If it is the former and arm-unknown-eabi doesn't meet your needs, I
> guess that providing a sample which builds for the arm-none-eabi
> target with just the regular gcc release could be a nice start.
> 
> For the latter, I believe that the best option would be to make
> crosstool-ng support remote repositories to be cloned and used for the
> build, similar to what Buildroot does with 'git' and 'svn' download
> methods for sources.
> I too have missed this feature at least once, to distribute a
> configuration which uses a custom remote source in a format more
> portable than a path to a local directory (from my machine).
> 
>> What is the recommended procedure to achieve what I like to do an which will
>> be accepted as patch?
> 
> You should follow the github flow and submit a pull request in:
> https://github.com/crosstool-ng/crosstool-ng
> 
> Erico
> 

--
For unsubscribe information see http://sourceware.org/lists.html#faq