> On 15 Apr 2020, at 11:41, Rasmus Villemoes wrote:
> On a somewhat related note, we're currently carrying this locally in
> order to build (link) the vxworks kernel image itself using gcc:
>
> diff --git a/gcc/config/vxworks.h b/gcc/config/vxworks.h
> index 0f604f1bcc4..06b4e2e6870 100644
> --
On 15/04/2020 10.52, Olivier Hainque wrote:
> Hi Rasmus,
>
> Thanks for your proposal.
>
> This is an issue we discussed a bit very recently
> https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543073.html
>
> and it's nice to see a proposal not requiring
> the replication of all the link spec
Hi Rasmus,
Thanks for your proposal.
This is an issue we discussed a bit very recently
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543073.html
and it's nice to see a proposal not requiring
the replication of all the link spec logic.
I had mixed feelings about a change to get gcc -r be
On Tue, 14 Apr 2020, Rasmus Villemoes wrote:
> On 06/04/2020 23.18, Joseph Myers wrote:
> > On Sat, 4 Apr 2020, Rasmus Villemoes wrote:
> >
> >> +#ifndef OUTFILES_SPEC
> >> +#define OUTFILES_SPEC "%o"
> >> +#endif
> >
> > A new target macro needs to be documented in tm.texi.in,
>
> Will do.
>
On 06/04/2020 23.18, Joseph Myers wrote:
> On Sat, 4 Apr 2020, Rasmus Villemoes wrote:
>
>> +#ifndef OUTFILES_SPEC
>> +#define OUTFILES_SPEC "%o"
>> +#endif
>
> A new target macro needs to be documented in tm.texi.in,
Will do.
> with tm.texi then being regenerated.
Please include information o
On Sat, 4 Apr 2020, Rasmus Villemoes wrote:
> +#ifndef OUTFILES_SPEC
> +#define OUTFILES_SPEC "%o"
> +#endif
A new target macro needs to be documented in tm.texi.in, with tm.texi then
being regenerated.
--
Joseph S. Myers
jos...@codesourcery.com
Commit 0b7fb27b698d (Fix and document -r option) broke building of
VxWorks modules, at least for our version of VxWorks. A VxWorks module
is a relocatable ELF file - the final link is done when the file is
linked in to the running kernel. So building with -r is
necessary. However, the module also n
