Attempt to get rid of -qrtems
Sebastian Huber
sebastian.huber at embedded-brains.de
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 rtems.org
> <mailto:chrisj at rtems.org>> 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:
https://sourceware.org/ml/binutils/2019-06/msg00275.html
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 embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the devel
mailing list