23.4.2012 2:59, rbmj kirjoitti:
I have been working on building a cross compiler to vxWorks on a debian
linux amd64 host. My problem is that I am having difficulty getting the
include directories to work correctly. To work correctly, I need to have
two include directories on the target: target/h, and
target/h/wrn/coreip.
Something like this? :
[root@localhost build]# gcc/cc1 -v
#include "..." search starts here:
#include <...> search starts here:
/opt/cross/lib/gcc/powerpc-wrs-vxworks/4.6.3/include
/opt/cross/lib/gcc/powerpc-wrs-vxworks/4.6.3/include-fixed
/opt/cross/lib/gcc/powerpc-wrs-vxworks/4.6.3/../../../../powerpc-wrs-vxworks/h/wrn/coreip
/opt/cross/lib/gcc/powerpc-wrs-vxworks/4.6.3/../../../../powerpc-wrs-vxworks/h
End of search list.
The first and second directory in the C search path are those
$target/$gcc-version dependent places for GCC's own and for
the fixed target standard headers. The last two are for the
"system (dependent) headers" and for the (unfixed) "standard
headers". All these are totally normal search places for a
crosscompiler using the traditional $tooldir scheme for
target headers, not the newer $sysroot ("native-GCC-alike")
scheme. The search order for the last two one can decide
oneself, here I assumed the 'h/wrn/coreip' wanted to be
searched before the 'h'...
With C++ the search path would be :
[root@localhost build]# gcc/cc1plus -v
#include "..." search starts here:
#include <...> search starts here:
/opt/cross/include/c++/4.6.3
/opt/cross/include/c++/4.6.3/powerpc-wrs-vxworks
/opt/cross/include/c++/4.6.3/backward
/opt/cross/lib/gcc/powerpc-wrs-vxworks/4.6.3/include
/opt/cross/lib/gcc/powerpc-wrs-vxworks/4.6.3/include-fixed
/opt/cross/lib/gcc/powerpc-wrs-vxworks/4.6.3/../../../../powerpc-wrs-vxworks/h/wrn/coreip
/opt/cross/lib/gcc/powerpc-wrs-vxworks/4.6.3/../../../../powerpc-wrs-vxworks/h
End of search list.
The '/opt/cross' of course resulted from :
--prefix=/opt/cross
and the C++ headers search root from :
--with-gxx-include-dir=/opt/cross/include/c++/4.6.3
in the 'configure' command (this far the C++ headers
have been target-independent, separating the target-
specific headers into their own '$target' subdir...
My configure command looks like this:
"$SRC/gcc-$GCC_VERSION/configure" \
--prefix="$PREFIX" \
--target=powerpc-wrs-vxworks \
--with-gnu-as \
--with-gnu-ld \
--with-headers="$SRC/gccdist/WindRiver/vxworks-6.3/target/h" \
--disable-shared \
--disable-libssp \
--disable-multilib \
--with-float=hard \
--enable-languages=c,c++ \
--enable-threads=vxworks \
--without-gconv \
--disable-libgomp \
--disable-nls \
--disable-libmudflap \
--with-cpu-PPC603
Right now I have to add target/h/wrn/coreip to the include path in
target directories (like libstdc++). I tried using CFLAGS and
C_INCLUDE_PATH, but these would not work as they would also override the
include path in host directories, so #include <stdio.h> had all SORTS of
issues... namely that it was the wrong stdio!
As you may have guessed it may be impossible to customize
the search path for headers without touching the sources
or doing some tinkering after running 'configure'. Fixing
the '$BUILD/gcc/Makefile' and there the following rows to
be like :
# Remake cpp.
PREPROCESSOR_DEFINES = \
-DGCC_INCLUDE_DIR=\"$(libsubdir)/include\" \
-DFIXED_INCLUDE_DIR=\"$(libsubdir)/include-fixed\" \
-DGPLUSPLUS_INCLUDE_DIR=\"$(gcc_gxx_include_dir)\" \
-DGPLUSPLUS_TOOL_INCLUDE_DIR=\"$(gcc_gxx_include_dir)/$(target_noncanonical)\"
\
-DGPLUSPLUS_BACKWARD_INCLUDE_DIR=\"$(gcc_gxx_include_dir)/backward\" \
-DLOCAL_INCLUDE_DIR=\"$(local_includedir)\" \
-DCROSS_INCLUDE_DIR=\"$(gcc_tooldir)/h/wrn/coreip\" \
-DTOOL_INCLUDE_DIR=\"$(gcc_tooldir)/h\" \
-DPREFIX=\"$(prefix)/\" \
-DSTANDARD_EXEC_PREFIX=\"$(libdir)/gcc/\" \
caused what was seen with the 'cc1* -v' (C preprocessor
included in 'cc1' and 'cc1plus' nowadays). The three
(target-dependent) directories ruling the C header places
originally were (in 'gcc/Makefile.in') :
-DLOCAL_INCLUDE_DIR=\"$(local_includedir)\" \
-DCROSS_INCLUDE_DIR=\"$(CROSS_SYSTEM_HEADER_DIR)\" \
-DTOOL_INCLUDE_DIR=\"$(gcc_tooldir)/include\" \
The CROSS_SYSTEM_HEADER_DIR usually is '$(gcc_tooldir)/sys-include'
in the traditional scheme (without the '--with-sysroot=$sysroot' in
the configure command). The LOCAL_INCLUDE_DIR is normally disabled
in 'gcc/cppdefault.c' for a traditional crosscompiler :
#if defined (CROSS_DIRECTORY_STRUCTURE) && !defined (TARGET_SYSTEM_ROOT)
# undef LOCAL_INCLUDE_DIR
# undef SYSTEM_INCLUDE_DIR
# undef STANDARD_INCLUDE_DIR
#else
# undef CROSS_INCLUDE_DIR
#endif
So commenting the '#undef' away and editing a new value for this
in the resulted '$BUILD/gcc/Makefile' one could get even a third
'target specific' search directory for the C headers! This being
searched before the fixed standard headers. And if one looks at
the 'gcc/cppdefault.c' one sees there being also a fourth place,
PREFIX_INCLUDE_DIR, for C headers. One only needs to define this
somewhere... Where, I cannot say, its use is a little fuzzy for
me :-(
And yes, I *am* building libstdc++. I changed the configure script to
build a static libstdc++ that I link into my kernel module so that I can
take advantage of new features and then use objcopy to localize those
symbols so they don't conflict with the kernel. If this is a bad
(stupid) idea then please tell me.
Cannot say anything about using libstdc++ with VxWorks :-(
Finally, is there a way to enable a build of libstdc++ without manually
changing the configure script?
You mean the :
*-*-vxworks*)
noconfigdirs="$noconfigdirs target-newlib target-libgloss
target-libstdc++-v3 ${libgcj}"
;;
I'm not sure but using '--enable-libstdc++-v3' could switch the
production on, if not then fixing 'configure' would be the easy
way (editing 'target-libstdc++-v3' away)...
