Re: Trouble building RTEMS from master

Should be fixed now. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine

Re: Tools for RTEMS 4.12

Hi, The issue of recursive calls of callocs was fixed in RTEMS mainline adding -fno-builtin in the calloc.c compilation, but we made a gcc patch in order to use -fno-builtin-calloc instead of -fno-builtin, this is more specific and disables only calloc builtin optimization. Currently there is an

Re: [rtems-source-builder commit] doc: fix link to patch for CVS

Are manuals on docs.rtems.org automatically regenerated or need to be hand-built? On Wed, Nov 4, 2015 at 2:54 PM, Gedare Bloom wrote: > Module:rtems-source-builder > Branch:master > Commit:6bef80f0260923d7274dc1bf3fe193df025772e8 > Changeset: >

Re: Tools for RTEMS 4.12

On 05/11/15 15:50, Daniel Gutson wrote: On Thu, Nov 5, 2015 at 11:41 AM, Sebastian Huber wrote: >Hello, > >I would like to add the tools for RTEMS 4.12 to the RSB. The question is >which GCC version should we use? Since our release process is so slow I

Re: Tools for RTEMS 4.12

Hi Sebastian, I see no problem with using the newer GCC assuming our development cycle is probably still at least 1yr+. Until we get good automation this is the case. Also, we are planning to apply to Google Code-In, and bumping the tool versions could be a set of tasks. If you would like to do

Re: Tools for RTEMS 4.12

On Thu, Nov 5, 2015 at 11:52 AM, Sebastian Huber wrote: > > > On 05/11/15 15:50, Daniel Gutson wrote: >> >> On Thu, Nov 5, 2015 at 11:41 AM, Sebastian Huber >> wrote: >>> >>> >Hello, >>> > >>> >I would like to add the tools

Re: Tools for RTEMS 4.12

On Thu, Nov 5, 2015 at 11:41 AM, Sebastian Huber wrote: > Hello, > > I would like to add the tools for RTEMS 4.12 to the RSB. The question is > which GCC version should we use? Since our release process is so slow I tend > to use GCC 6 since it includes support

[PATCH] LPC1768: Fix compilation error

The LPC1768 variants have a gpio.h file whose name clashes with the gpio.h from the new GPIO API. This results on the BSPs failing to compile. This patch renames the LPC1768 gpio.* files to lpc-gpio.*, as it's done on other BSPs (e.g. Beaglebone). Closes #2441. ---