Re: Why is fixincludes not doing anything?

[rbmj <rbmj@verizon.net>]

On 05/26/2012 04:00 PM, Ian Lance Taylor wrote:
> rbmj<rbmj@verizon.net>  writes:
>
>> On 05/25/2012 07:18 PM, Ian Lance Taylor wrote:
>>> rbmj<rbmj@verizon.net>   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