toolchain versions (was Re: compile error in dwmac-desc-enh.c)

[Gedare Bloom]

On Thu, Aug 7, 2014 at 9:22 PM, Chris Johns <chrisj at rtems.org> wrote:
> On 8/08/2014 6:49 am, Joel Sherrill wrote:
>>
>> That link is for the newlib patch not the gcc patch listed above.
>
>
> Ah sorry I missed that part of the email. I have no idea about this patch
> and what it attempts to do. I have not seen any posts or discussion about it
> and same goes for the SOURCES/4.11 directory.
>
> IMO we should not have a SOURCES/4.11 directory until 4.11 is released so I
> think it should be emptied. When 4.11 is released this directory should
> contain all the approved source and to be approved there needs to be real
+1

> test results from RTEMS where possible. Just building the tools and RTEMS is
> not sufficient. We have not reached a point where every architecture or BSP
> can be tested however we have made real progress and so as I said where
> possible we should run the tests and get the results. RTEMS should also make
> available the ability for users to run the tests and compare the results.
> Users being able to validate the tools they have against the expected
> results is very important.
>
> The 4.11 tools are currently a mix of 4.8.3 and 4.9.1 with some upstream
> patches and newlib-26-Jul-2014 [1]. The gcc-4.9.1 release is being used for
> some targets that do not build or are not supported on 4.8.3, eg NIOS2. The
> recent newlib is required to get the RTEMS head to build.
>
> Back to the point on rtems-tools being the master. It is as well as
> references to suitable web sites that host and provide support for the
> upstream project. For example the NIOS2 patch being used by the RSB is
> http://patchwork.ozlabs.org/patch/364504/. The RSB references this patch
> directly
> http://git.rtems.org/rtems-source-builder/tree/rtems/config/4.11/rtems-nios2.bset#n19.
>
Perhaps there should be a generic config file in rtems-tools that
provides links to these external patches? RSB would then parse that
config file. It would make it easier for other packagers to be sure
they are building the right toolchain. This will separate the policy
of deciding what should go into a toolchain (versions, patches, etc)
from the mechanism that builds it, e.g. RSB or some other packager.
-Gedare

> The RTEMS project defines the tool set at the source level for a release and
> anyone can take that and package it anyway they like where ever they like.
> The RSB is just one possible way. Anyone packaging the tools can vary them
> anyway they like and so users need to decide on using those tools based on
> there merits.
>
> Chris
>
> [1]
> http://git.rtems.org/rtems-source-builder/tree/rtems/config/tools/rtems-gcc-4.8.3-newlib-cvs-1.cfg
> http://git.rtems.org/rtems-source-builder/tree/rtems/config/tools/rtems-gcc-4.9.1-newlib-cvs-1.cfg
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users