On 24/08/2018 10:22, Joel Sherrill wrote: > > > On Thu, Aug 23, 2018, 6:53 PM Chris Johns <chr...@rtems.org > <mailto:chr...@rtems.org>> wrote: > > On 24/08/2018 08:33, Matthew Gann wrote: > > I've modified the c/src/bsp.pc.in <http://bsp.pc.in> <http://bsp.pc.in> > file and still see the same > > issues (still need the -Dmpc604, and it still fails on fat_ramdisk). > It looks > > like the -qrtems argument did move in the argument list, but didn't fix > this > > particular issue. See the output below. > > I've also tried disabling the build of the fat_ramdisk (and others > following it) > > and it still broke. Is there a better starting place than the > examples-v2 > for 4.11? > > > > I suggest updating rtems_waf to the latest and see how it goes on 4.11. > > Hmmm, that will not work, it looks like the rtems_waf module has not been > updated to point to the new repo location. That will need a ticket. I did > not do > the move and so I am not sure what git magic is needed. > > > Mentioning the -Dmpc604 reminds me that I worked recently to remove the need > for > any bsp.to <http://bsp.to> use a -Dxxx. This was fragile since user code had > to > use exactly the same flags. > > Chris is rtems_waf stripping those out? It was only maybe a dozen bsps that > used it. >
It may. The rtems_waf processing needs to play with the flags because RTEMS does not separate the machine, warning and optimisation flags. The flags need to be filtered so we avoid building a 3rd party package with warning or optimisation options used to build RTEMS. They may not be suitable. We may need to teach rtems_waf about these flags. The code has support for tweaks for specific BSPS, we just need to find what needs to be tweaked. Chris _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
