On 22/12/2017 02:01, Joel Sherrill wrote: > I'm not opposed to this but it requires even more delicate editing that I > can't > easily test.
If something breaks and it is reported we can look at fixing it. If something breaks and it is not reported is it broken? ;) > We can get rid of bsp_specs and do this largely at the same time. The > specifications in GCC will have to be tinkered with to address what's left in > bsp_specs so the specs can do this. I think GCC's default configuration should be user focused and not BSP or internally RTEMS focused. I see this meaning GCC's model is the same for all BSPs and the options to access a BSP are similar. > But I haven't figured out precisely what to do with gcc at this point. The difficult part is locating start.o and similar object files. RTEMS currently implements a horrible hack using -B. This option not only locates a bsp_specs file it also adds a search path for locating .o and other files. I have only just uncovered this as part of removing preinstall and it is a horrible problem to solve. For example what happens if I create start.o in my application and provide it on the command line to the linker with a -B to the location RTEMS's start.o is located? Does GCC know what I want, is this option order dependent or something else? A simple solution here is use RTEMS specific names but the idea of needing -B seems wrong. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
