On 04/25/2012 03:01 AM, Kai Ruottu wrote:
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".
So you manually copied over the c-headers to
/opt/cross/powerpc-wrs-vxworks/h? I'm not exactly familiar with the gcc
compile process and when I specify --with-headers=FOO it copies the
contents of FOO to /usr/local/powerpc-wrs-vxworks/sys-include (where my
--prefix=/usr/local).
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'.
I guessed, but it seems, well, wrong. It seems like there should be a
way to say --target-include=BAR. Changing the presets might mess with a
package that installs headers to, say $(gcc_tooldir)/include, or
something. Thanks for showing me those locations, and I'll do that if I
have to. But manually editing the Makefile every time I configure is a
pain, and if I change some options a patch might reject. Maybe some sed
trickery would work...
Right now, I just have a temporary patch that inserts include stubs into
the target/h that #include the respective file in target/h/wrn/coreip,
as there's only a handful of files that are used from the wrn/coreip
include directory by GCC. Then there's a big note that says something
along the lines of "always run gcc with -isystem
/usr/local/powerpc-wrs-vxworks/wind_base/target/h/wrn/coreip", and I
unapply the patch. If I make a change to how I build GCC, it'd be to
something less smelly and less work than that .
The real problem is the stupid vxWorks header files, but I can only
justify so much modification as fair use. Any major changes to their
header files beyond fixing (for example) whitespace that makes gcc 4.7.0
think it's using a user-defined literal in its assert macro isn't really
justifiable. Proprietary codebases...
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
I doubt many would, as most use the version that's included on the
target. But I want to try using some C++11 features, so I need modern
libstdc++, libgcc, etc. Just an experiment...
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)...
That's what I've been doing. But this changes from version to version
of GCC. I'll try --enable-libstdc++-v3 and see if that works...
Thanks for the help!
PS: Sorry Kai Ruottu I accidentally sent this to you first instead of
to the list :-(
--
rbmj
