[patch] specialize paths to version.h in _vxworks-versions.h

[Olivier Hainque <hainque@adacore.com>]

[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]


The _vxworks-versions.h runtime file helps us control
the compilation of some library components depending on
the OS version extracted out of a system header.

The system header name is "version.h", and gcc has a
"version.h" file of its own.

gcc's version.h is now generated and the current
#include <version.h> from _vxworks-versions.h gets the gcc
instance instead of the OS one, resulting in build failures
from

  #if !defined(_WRS_VXWORKS_MAJOR)
  #error "_WRS_VXWORKS_MAJOR undefined"
  #endif


This change introduces a twist in the way
_vxworks-versions.h #includes version.h, using a relative
path with components that will match in the OS include
dirs only.

The actual relative path is conditioned on _VSB_CONFIG_FILE
to accommodate a change in the include dirs organisation between
VxWorks 6 and 7.

With this, our gcc-12 based builds now pass for both
powerpc-vx6 and a few cpu families with vxworks7, and a
a sanity check build with mainline also passes for
ppc64-vxworks7.

Will commit to mainline shortly,

Cheers,

Olivier


[-- Attachment #2: 0001-Specialize-paths-to-version.h-in-_vxworks-versions.h.patch --]
[-- Type: application/octet-stream, Size: 2741 bytes --]

From ce304abca4fbce6b636a19c1c9254f68d033bc58 Mon Sep 17 00:00:00 2001
From: Olivier Hainque <hainque@adacore.com>
Date: Fri, 7 Oct 2022 10:12:26 +0000
Subject: [PATCH] Specialize paths to version.h in _vxworks-versions.h

The _vxworks-versions.h runtime file helps us control
the compilation of some library components depending on
the OS version extracted out of a system header.

The system header name is "version.h", and gcc has a
"version.h" file of its own.

gcc's version.h is now generated and the current
instance instead of the OS one, resulting in build failures
from

  #if !defined(_WRS_VXWORKS_MAJOR)
  #error "_WRS_VXWORKS_MAJOR undefined"
  #endif

This change introduces a twist in the way
_vxworks-versions.h #includes version.h, using a relative
path with components that will match in the OS include
dirs only.

The actual relative path is conditioned on _VSB_CONFIG_FILE
to accommodate a change in the include dirs organisation between
VxWorks 6 and 7.

2022-10-07  Olivier Hainque  <hainque@adacore.com>

gcc/
	* config/vxworks/_vxworks-version.h: Use OS specific
	paths in #include of version.h.
---
 gcc/config/vxworks/_vxworks-versions.h | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/gcc/config/vxworks/_vxworks-versions.h b/gcc/config/vxworks/_vxworks-versions.h
index 15e8bfeb4a6..994dda90643 100644
--- a/gcc/config/vxworks/_vxworks-versions.h
+++ b/gcc/config/vxworks/_vxworks-versions.h
@@ -23,15 +23,24 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 #define _VXWORKS_VERSIONS_H  1
 
 /* All we need is access to the bare _WRS_VXWORKS_MAJOR/MINOR macros,
-   exposed by version.h or already provided somehow (e.g. with a self
-   spec for some reason).  When resorting to system headers, cheat a
-   bit to make sure we don't drag additional header files, which can
-   easily cause #include ordering nightmares.  */
+   exposed by version.h or already provided somehow (e.g. with a self spec
+   for some reason).  When resorting to system headers, use typical os
+   paths to prevent possible confusion with a gcc version of version.h
+   visible during the build and temporarily #undef _WRS_KERNEL to prevent
+   indirect inclusion of internal header files, which can easily cause
+   #include ordering nightmares.  */
 
 #if !defined(_WRS_VXWORKS_MAJOR)
+
+#if defined(_VSB_CONFIG_FILE)
+#define _VXWORKS_VERSION_H <../public/version.h>
+#else
+#define _VXWORKS_VERSION_H <../h/version.h>
+#endif
+
 #pragma push_macro("_WRS_KERNEL")
 #undef _WRS_KERNEL
-#include <version.h>
+#include _VXWORKS_VERSION_H
 #pragma pop_macro("_WRS_KERNEL")
 #endif
 
-- 
2.25.1


[-- Attachment #3: Type: text/plain, Size: 2 bytes --]