> On 15 Apr 2020, at 11:41, Rasmus Villemoes <r...@rasmusvillemoes.dk> 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
> --- a/gcc/config/vxworks.h
> +++ b/gcc/config/vxworks.h
> @@ -112,7 +112,7 @@ along with GCC; see the file COPYING3. If not see
> will treat it as an unrecognized option. */
> #undef VXWORKS_LINK_SPEC
> #define VXWORKS_LINK_SPEC \
> -"%{!mrtp:-r} \
> +" \
> %{!shared: \
> %{mrtp:-q %{h*} \
> %{R*} %{!T*: %(link_start) } \
>
> and then module builds must pass -r [or perhaps -Wl,-r depending on how
> the above gets solved] explicitly. From the link above, it sounds like
> you are already passing -r explicitly and not relying on lack of -mrtp
> implying it, so would the above be acceptable for upstream (with proper
> changelog and whitespace cleanup of course)?
This is a sensitive area and, while I understand the rationale,
I think we'd first need to experiment quite a bit in-house to go
with such a change.
As I mentioned in the thread referenced a couple of messages up,
the issue is not so much our own uses of the toolchain but assumptions
by possible invocations through IDE and Makefiles part of the
VxWorks environment.
I'll discuss with the team here.
Olivier
