Re: Why is fixincludes not doing anything?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 05/26/2012 04:00 PM, Ian Lance Taylor wrote:
rbmj<rbmj@xxxxxxxxxxx>  writes:

On 05/25/2012 07:18 PM, Ian Lance Taylor wrote:
rbmj<rbmj@xxxxxxxxxxx>   writes:

My configure call was:

../gcc-4.7.0/configure --prefix=/usr --target=powerpc-wrs-vxworks
--with-gnu-as --with-gnu-ld
--with-headers=../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

I don't use --with-sysroot; I use --with-headers.  So do I need to use
a different configuration?  And how can I achieve the same effect
using --with-sysroot as I did with --with-headers if that *is* the
issue.
As the installation doc says, the --with-sysroot option is the new
replacement for the --with-headers option.  So if you can, try using
--with-sysroot.
I happen to prefer the 'traditional' layout with everything in
$PREFIX/powerpc-wrs-vxworks/{include,lib,bin}.  With the sysroot as
$PREFIX/powerpc-wrs-vxworks, then target includes are
/usr/powerpc-wrs-vxworks/usr/include, which is ugly IMHO.
You can use --with-native-system-header-dir=/include to avoid that
specific issue.


Still, fixincludes doesn't appear to do anything.  Where should be
fixed headers go in the build tree?  I can't find them:
In the build directory they should wind up in gcc/include-fixed.

Does the file gcc/stmp-fixinc get created in the build directory?

Does the output of make have the line "The directory that should contain
system headers does not exist" anywhere?  It would not necessarily cause
an error.
It does not.  Everything appears to be fine.

I checked again, this time limits.h pops up in that directory. So it appears to be doing something now.

My theory is that fixincludes is running for the host OS, but not for the cross targets (libgcc, etc. in sysroot). But I don't really know for sure. Maybe the mach = *-*-vxworks isn't what it's supposed to be - that could also be the problem. Or something else entirely.

Again, thanks for the help!

Robert Mason


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux