* I like to add arm-none-eabi support to crosstool-ng
@ 2015-08-27 23:44 Jasmin J.
2015-08-28 15:31 ` Erico Nunes
0 siblings, 1 reply; 3+ messages in thread
From: Jasmin J. @ 2015-08-27 23:44 UTC (permalink / raw)
To: crossgcc
Hello!
I am new to the list, but I know crosstool-ng since long time. I even started
with the scripts very long time ago.
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/
Currently I haven't found any configuration in crosstool-ng which would
support building out of an SVN repository. There are no snapshots of this
branch available (at least I couldn't find them), too. So I decided to use
the custom option with a local SVN tree for my build.
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.
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).
What is the recommended procedure to achieve what I like to do an which will
be accepted as patch?
BR
Jasmin
--
For unsubscribe information see http://sourceware.org/lists.html#faq
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: I like to add arm-none-eabi support to crosstool-ng
2015-08-27 23:44 I like to add arm-none-eabi support to crosstool-ng Jasmin J.
@ 2015-08-28 15:31 ` Erico Nunes
2015-08-28 22:16 ` Jasmin J.
0 siblings, 1 reply; 3+ messages in thread
From: Erico Nunes @ 2015-08-28 15:31 UTC (permalink / raw)
To: Jasmin J.; +Cc: crossgcc
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: I like to add arm-none-eabi support to crosstool-ng
2015-08-28 15:31 ` Erico Nunes
@ 2015-08-28 22:16 ` Jasmin J.
0 siblings, 0 replies; 3+ messages in thread
From: Jasmin J. @ 2015-08-28 22:16 UTC (permalink / raw)
To: crossgcc
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-08-28 22:16 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-27 23:44 I like to add arm-none-eabi support to crosstool-ng Jasmin J.
2015-08-28 15:31 ` Erico Nunes
2015-08-28 22:16 ` Jasmin J.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).