Attempt to get rid of -qrtems

Joel Sherrill joel at
Mon Jul 1 00:41:04 UTC 2019

On Sun, Jun 30, 2019, 7:09 PM Chris Johns <chrisj at> wrote:

> On 28/6/19 6:02 pm, Sebastian Huber wrote:
> > On 28/06/2019 01:37, Chris Johns wrote:
> >> On 27/6/19 10:08 pm, Sebastian Huber wrote:
> >>> I would like to get rid of the -qrtems command for normal RTEMS
> applications.
> >> I do not think you can remove -qrtems as it will break all existing
> configure
> >> scripts. The default needs to be stubs.
> >
> > Ok, this was just some side-effect of an attempt to get rid of the
> bsp_specs.
> > What about the attached patch.
> I am sorry I do not know without testing it.
> > You can add startfiles via the linker command file. Is it possible to
> add also
> > endfiles? I didn't find anything in the GNU ld documentation about this.
> Having the start files in linkercmd files is something I have wondered
> about for
> a long time and I think it is a good idea. I think anything that removes
> our
> dependence on per BSP or even external specs file is a good thing.
> I think the way we have a BPS centric build and install makes it difficult
> to
> generalise. For example any configure script that tests for networking
> fails
> without the full BSP set of options plus -lbsd.

I believe I moved some start files to linkcmds when I was working to get
the bsp_specs files to be more similar and move parts to gcc where common.
My first step was reducing differences within an architecture across the
BSPs and looking for common pieces to move to gcc. It was tedious but
quickly became obvious we had disabled some behavior we turned around and
added via the bsp_specs.

I think I have a specs branch on my gcc clone at the office. I will post
what I had when (if) I find it.

> Chris
> _______________________________________________
> devel mailing list
> devel at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the devel mailing list