Attempt to get rid of -qrtems

[Sebastian Huber]

On 01/07/2019 07:23, Sebastian Huber wrote:
> 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.

It seems that the linker script doesn't support something for endfiles 
currently:

https://www.sourceware.org/ml/binutils/2019-07/msg00007.html

-- 
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.