Attempt to get rid of -qrtems

Sebastian Huber sebastian.huber at
Mon Jul 1 05:23:10 UTC 2019

On 01/07/2019 02:41, Joel Sherrill wrote:
> On Sun, Jun 30, 2019, 7:09 PM Chris Johns <chrisj at 
> <mailto: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.

I would prefer a solution outside of GCC, e.g. the linker command files. 
For the startfiles this should work. I don't know how you can support 
endfiles via linker command files:

This could be a show stopper for using linker command files.

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.huber at
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

More information about the devel mailing list