Hello, To circumvent unfortunate header files naming conflicts, the VxWorks port resorts to various tricks. One of them still on mainline consists in this twist in libgcc/config/t-vxworks:
# This ensures that the correct target headers are used; some
# VxWorks system headers have names that collide with GCC's
# internal (host) headers, e.g. regs.h.
LIBGCC2_INCLUDES = -nostdinc -I \
`case "/$$(MULTIDIR)" in \
*/mrtp*) echo $(WIND_USR)/h ;; \
*) echo $(WIND_BASE)/target/h ;; \
esac`
There is an alternate approach to this also on mainline, via
fixincludes.
Both methods incur a couple of problems, and I'll soon send
messages to discuss possible resolutions.
In the most immediate term, the current setup causes a libgcc
build failure for e.g. powerpc-wrs-vxworks (for VxWorks 6.9 in
my case), with, among other things:
In file included from
/chelles.a/users/hainque/bld-gcc/gcc/include-fixed/unistd.h:13:0,
from
/chelles.b/users/hainque/gcc-svn/libgcc/../gcc/tsystem.h:102,
from /chelles.b/users/hainque/gcc-svn/libgcc/libgcc2.c:27:
.../powerpc-wrs-vxworks/sys-include/ioLib.h:159:10: fatal error: net/uio.h: No
such file or directory
VxWorks headers perform #includes relative not only to target/h,
but also to target/h/wrn/coreip.
The attached patch fixes this by twisting the LIBGCC2_INCLUDES
definition above so it passes the additional -I.
Committing to mainline, after testing that it cures the aforementioned error.
This might be turn out only a temporary measure pending results of further
discussions on other aspects regarding the workarounds for the header file
name conflicts, but this is all very intricate and I find it easier to proceed
incrementally.
With Kind Regards,
Olivier
2017-06-08 Olivier Hainque <hain...@adacore.com>
libgcc/
* config/t-vxworks (LIBGCC2_INCLUDES): Add wrn/coreip to the
set of -I options, support for direct inclusions of net/uio.h
by VxWorks header files via ioLib.h.
vx-coreip.diff
Description: Binary data
