Fixincludes permanence & questions on cross compilers

Fixincludes permanence & questions on cross compilers

[rbmj]

Hi all,

Two questions:

1.  Are fixincludes hacks only active during build-time (e.g. they do 
not replace the actual file) or are they permanent?  If they are only 
temporary/local to gcc, but they need to be permanent, is there a way to 
specify this?

2.  On cross compilers, fixincludes does not appear (to my uneducated 
eye) to be applied to my headers (then again, I may have written the 
hacks wrong) located in sys-include.  Does fixincludes not affect 
headers in sys-include or am I not looking hard enough?

If somebody can explain in a bit more detail how fixincludes works (I 
read the README but it only defines the formatting), please do.

The hacks I'm trying to apply are at the end of this email, if it helps.

Thanks,

Robert Mason

/*
  *  Wrap VxWorks ioctl to keep everything pretty
  */
fix = {
     hackname    = vxworks_ioctl_macro;
     files       = ioLib.h;
     test        = " -r vxWorks.h ";

     c_fix       = format;
     c_fix_arg   = "%0\n"
         "#define ioctl(fd, func, arg) ((ioctl)((fd), (func), 
((int)(arg))))\n";
     c_fix_arg   = "extern[\t ]+int[\t ]+ioctl[\t ]*\([\t ,[:alnum:]]\);";

     test_text   = "`touch vxWorks.h`"
         "extern int ioctl ( int asdf1234, int jkl, int qwerty ) ;";
};

/*
  *  Work around same-named gcc header regs.h in taskLib.h on VxWorks
  */
fix = {
     hackname    = vxworks_tasklib_regs;
     files       = taskLib.h;
     test        = " -r vxWorks.h ";

     select      = "#[\t ]*include[\t ]+<regs.h>";
     c_fix       = format;
     c_fix_arg   = "#include <arch/../regs.h>";

     test_text   = "`touch vxWorks.h`"
         "#include <regs.h>\n";
};

/*
  *  This hack makes makes unistd.h more POSIX-compliant on VxWorks
  */
fix = {
     hackname    = vxworks_unistd;
     files       = unistd.h;
     test        = " -r vxWorks.h ";

     select      = "#[\t ]*include[\t ]+<vxWorks.h>";
     c_fix       = format;
     c_fix_arg   = "%0\n#include <ioLib.h>\n"
         "#ifndef STDIN_FILENO\n"
         "#define STDIN_FILENO 0\n"
         "#endif\n"
         "#ifndef STDOUT_FILENO\n"
         "#define STDOUT_FILENO 1\n"
         "#endif\n"
         "#ifndef STDERR_FILENO\n"
         "#define STDERR_FILENO 2\n"
         "#endif\n";

     test_text   = "`touch vxWorks.h`"
         "#include <vxWorks.h>\n";
};

/*
  *  This hack makes write const-correct on VxWorks
  */
fix = {
     hackname    = vxworks_write_const;
     files       = ioLib.h;
     test        = " -r vxWorks.h ";

     c_fix       = format;
     c_fix_arg   = "extern int  write (int, const char*, size_t);";
     c_fix_arg   = "extern[\t ]+int[\t ]+write[\t ]*\("
         "[\t ]*int[\t ]*,"
         "[\t ]*char[\t ]*\*[\t ]*,"
         "[\t ]*size_t[\t ]*\)[\t ]*;";

     test_text   = "`touch vxWorks.h`"
         "extern int write ( int , char * , size_t ) ;";
};

Re: Fixincludes permanence & questions on cross compilers

[Jonathan Wakely]

On 23 May 2012 17:52, rbmj wrote:
> Hi all,
>
> Two questions:
>
> 1.  Are fixincludes hacks only active during build-time (e.g. they do not
> replace the actual file) or are they permanent?  If they are only
> temporary/local to gcc, but they need to be permanent, is there a way to
> specify this?

They are permanent, but they don't replace the file. GCC puts the
fixed headers in a directory which it searches before the system
directories, so it finds the fixed ones before the original ones.

> 2.  On cross compilers, fixincludes does not appear (to my uneducated eye)
> to be applied to my headers (then again, I may have written the hacks wrong)
> located in sys-include.  Does fixincludes not affect headers in sys-include
> or am I not looking hard enough?

If you're expecting the original headers to be replaced then you're
looking in the wrong place.

Search under the GCC installation tree, you should find the fixed
version of the header.

Re: Fixincludes permanence & questions on cross compilers

[rbmj]

On 05/23/2012 01:27 PM, Jonathan Wakely wrote:
> On 23 May 2012 17:52, rbmj wrote:
>> 1.  Are fixincludes hacks only active during build-time (e.g. they do not
>> replace the actual file) or are they permanent?  If they are only
>> temporary/local to gcc, but they need to be permanent, is there a way to
>> specify this?
> They are permanent, but they don't replace the file. GCC puts the
> fixed headers in a directory which it searches before the system
> directories, so it finds the fixed ones before the original ones.
>
>> 2.  On cross compilers, fixincludes does not appear (to my uneducated eye)
>> to be applied to my headers (then again, I may have written the hacks wrong)
>> located in sys-include.  Does fixincludes not affect headers in sys-include
>> or am I not looking hard enough?
> If you're expecting the original headers to be replaced then you're
> looking in the wrong place.
>
> Search under the GCC installation tree, you should find the fixed
> version of the header.
>

OK, so I went into fixincludes/inclhack.def and added this rule:

/*
  *  This hack makes makes unistd.h more POSIX-compliant on VxWorks
  */
fix = {
     hackname    = vxworks_tasklib_regs;
     files       = taskLib.h;
     test        = " -r vxWorks.h ";

     select      = "#[\t ]*include[\t ]+<regs.h>";
     c_fix       = format;
     c_fix_arg   = "#include <arch/../regs.h>";

     test_text   = "`touch vxWorks.h taskLib.h`"
         "#include <regs.h>\n";
};

I then ran genfixes and then went in to my build directory.  I ran make 
check.  This was in fixincludes/test/inc/taskLib.h:

#if defined( VXWORKS_TASKLIB_REGS_CHECK )
#include <regs.h>

#endif  /* VXWORKS_TASKLIB_REGS_CHECK */

and I saw this in tests/res/taskLib.h:

#if defined( VXWORKS_TASKLIB_REGS_CHECK )
#include <arch/../regs.h>

#endif  /* VXWORKS_TASKLIB_REGS_CHECK */

So it looks good. I deleted the fixincludes subdir and then ran make. 
However, when I get to libgcc:

In file included from ../../../gcc-4.7.0/libgcc/../gcc/regs.h:25:0,
                  from /usr/powerpc-wrs-vxworks/sys-include/taskLib.h:213,
                  from ../../../gcc-4.7.0/libgcc/config/vxlib.c
<errors />

These errors go away if i run sed -i.orig -e 
's|<regs.h>|<arch/../regs.h>|' /usr/powerpc-wrs-vxworks/taskLib.h

So taskLib.h is still including regs.h, not arch/../regs.h like it 
should.  I go into the build directory, and type find | grep taskLib. 
The only thing I get are the two in fixincludes/tests - there's no file 
in GCC's build tree.

taskLib.h and vxWorks.h are in /usr/powerpc-wrs-vxworks/sys-include.  I 
configured gcc with the following command line:

../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 --enable-threads=vxworks --without-gconv 
--disable-libgomp --disable-nls --disable-libmudflap --with-cpu-PPC603

What is the problem here?  Do I need to manually specify to run fixincludes?

Thanks,

Robert Mason

Why is fixincludes not doing anything? (was: Re: Fixincludes permanence & questions on cross compilers)

[rbmj]

On 05/23/2012 02:03 PM, rbmj wrote:
> OK, so I went into fixincludes/inclhack.def and added this rule:
>
> /*
>  *  This hack makes makes unistd.h more POSIX-compliant on VxWorks
>  */
> fix = {
>     hackname    = vxworks_tasklib_regs;
>     files       = taskLib.h;
>     test        = " -r vxWorks.h ";
>
>     select      = "#[\t ]*include[\t ]+<regs.h>";
>     c_fix       = format;
>     c_fix_arg   = "#include <arch/../regs.h>";
>
>     test_text   = "`touch vxWorks.h taskLib.h`"
>         "#include <regs.h>\n";
> };
>
> I then ran genfixes and then went in to my build directory.  I ran 
> make check.  This was in fixincludes/test/inc/taskLib.h:
>
> #if defined( VXWORKS_TASKLIB_REGS_CHECK )
> #include <regs.h>
>
> #endif  /* VXWORKS_TASKLIB_REGS_CHECK */
>
> and I saw this in tests/res/taskLib.h:
>
> #if defined( VXWORKS_TASKLIB_REGS_CHECK )
> #include <arch/../regs.h>
>
> #endif  /* VXWORKS_TASKLIB_REGS_CHECK */
>
> So it looks good. I deleted the fixincludes subdir and then ran make. 
> However, when I get to libgcc:
>
> In file included from ../../../gcc-4.7.0/libgcc/../gcc/regs.h:25:0,
>                  from /usr/powerpc-wrs-vxworks/sys-include/taskLib.h:213,
>                  from ../../../gcc-4.7.0/libgcc/config/vxlib.c
> <errors />
>
> These errors go away if i run sed -i.orig -e 
> 's|<regs.h>|<arch/../regs.h>|' /usr/powerpc-wrs-vxworks/taskLib.h
>
> So taskLib.h is still including regs.h, not arch/../regs.h like it 
> should.  I go into the build directory, and type find | grep taskLib. 
> The only thing I get are the two in fixincludes/tests - there's no 
> file in GCC's build tree.
>
> taskLib.h and vxWorks.h are in /usr/powerpc-wrs-vxworks/sys-include.  
> I configured gcc with the following command line:
>
> ../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 --enable-threads=vxworks --without-gconv 
> --disable-libgomp --disable-nls --disable-libmudflap --with-cpu-PPC603
>
> What is the problem here?  Do I need to manually specify to run 
> fixincludes?
>

Refine my question: anyone know why fixincludes does not appear to be 
doing *anything*?  I can't seem to find any fixed headers anywhere in 
GCC's build tree.  And the compile keeps failing...

Thanks,

Robert Mason

Re: Why is fixincludes not doing anything? (was: Re: Fixincludes permanence & questions on cross compilers)

[Ian Lance Taylor]

rbmj <rbmj@verizon.net> writes:

> Refine my question: anyone know why fixincludes does not appear to be
> doing *anything*?  I can't seem to find any fixed headers anywhere in
> GCC's build tree.  And the compile keeps failing...

In your specific case, I don't know.  But it is possible for a target to
disable fixincludes by setting STMP_FIXINC in a config/CPU/t-XXX file.
Or, since this is a cross-compiler, GCC may simply be confused about
where to find the header files that it is supposed to fix.  Normally
those header files will be found in the directory printed by gcc
-print-sysroot-headers-suffix.  What does that print for you?  Did you
configure GCC with the right --with-sysroot option?

Ian

Re: Why is fixincludes not doing anything?

[rbmj]

On 05/25/2012 09:59 AM, Ian Lance Taylor wrote:
> rbmj<rbmj@verizon.net>  writes:
>
>> Refine my question: anyone know why fixincludes does not appear to be
>> doing *anything*?  I can't seem to find any fixed headers anywhere in
>> GCC's build tree.  And the compile keeps failing...
> In your specific case, I don't know.  But it is possible for a target to
> disable fixincludes by setting STMP_FIXINC in a config/CPU/t-XXX file.
> Or, since this is a cross-compiler, GCC may simply be confused about
> where to find the header files that it is supposed to fix.  Normally
> those header files will be found in the directory printed by gcc
> -print-sysroot-headers-suffix.  What does that print for you?  Did you
> configure GCC with the right --with-sysroot option?

Maybe that's the error:

./gcc/xgcc -print-sysroot-headers-suffix
xgcc: fatal error: not configured with sysroot headers suffix

xgcc is the compiler in question right?  . is the build directory.  I 
believe xgcc is the compiler that compiles all of the cross targets (lib*).

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.

Thanks!

Robert Mason

Re: Why is fixincludes not doing anything?

[Ian Lance Taylor]

rbmj <rbmj@verizon.net> writes:

> On 05/25/2012 09:59 AM, Ian Lance Taylor wrote:
>> rbmj<rbmj@verizon.net>  writes:
>>
>>> Refine my question: anyone know why fixincludes does not appear to be
>>> doing *anything*?  I can't seem to find any fixed headers anywhere in
>>> GCC's build tree.  And the compile keeps failing...
>> In your specific case, I don't know.  But it is possible for a target to
>> disable fixincludes by setting STMP_FIXINC in a config/CPU/t-XXX file.
>> Or, since this is a cross-compiler, GCC may simply be confused about
>> where to find the header files that it is supposed to fix.  Normally
>> those header files will be found in the directory printed by gcc
>> -print-sysroot-headers-suffix.  What does that print for you?  Did you
>> configure GCC with the right --with-sysroot option?
>
> Maybe that's the error:
>
> ./gcc/xgcc -print-sysroot-headers-suffix
> xgcc: fatal error: not configured with sysroot headers suffix
>
> xgcc is the compiler in question right?  . is the build directory.  I
> believe xgcc is the compiler that compiles all of the cross targets
> (lib*).

Yes.

> 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.

Otherwise, I'm not entirely sure.  The Makefile rules for running
fixincludes are pretty tangled.

Ian

Re: Why is fixincludes not doing anything?

[rbmj]

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.

So I guess I'll go with the sysroot /opt/powerpc-wrs-vxworks - in my 
opinion it's slightly less ugly, though I have a (perhaps irrational) 
dislike of putting things in /opt.

> Otherwise, I'm not entirely sure.  The Makefile rules for running
> fixincludes are pretty tangled.

OK, so I reconfigured:

   $ ../gcc/configure --prefix=/usr --target=powerpc-wrs-vxworks 
--with-gnu-as --with-gnu-ld --with-sysroot=/opt/powerpc-wrs-vxworks 
--disable-shared --disable-libssp --disable-multilib --with-float=hard 
--enable-languages=c,c++,fortran --enable-threads=vxworks 
--without-gconv --disable-libgomp --disable-nls --disable-libmudflap 
--with-cpu-PPC603 --disable-symvers --enable-libstdc++-v3

And I copied /usr/powerpc-wrs-vxworks/sys-include to 
/opt/powerpc-wrs-vxworks/usr/include (so 
/opt/powerpc-wrs-vxworks/usr/include/vxWorks.h, for example, is valid).

Still, fixincludes doesn't appear to do anything.  Where should be fixed 
headers go in the build tree?  I can't find them:

[in build directory] $ find | grep unistd
$

Repeat for the other includes I'm trying to fix.  I can't find anything.

Looking in the fixincludes subdir, there doesn't appear to be any 
headers in there.  And I can't find anywhere else where it seems they 
should be stashed.

Thanks for your help,

Robert Mason

Re: Why is fixincludes not doing anything?

[rbmj]

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

Re: Why is fixincludes not doing anything?

[rbmj]

On 05/26/2012 04:53 PM, rbmj wrote:
> 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.
>

Anyone know about fixincludes specifically on cross compilers?  Does it 
run fixincludes for both host and target (it seems like it should)?  
Where is each directory - if host is gcc/include-fixed, where is 
target?  And if I run with --target=powerpc-wrs-vxworks, then a 
fixincludes rule with a mach = *-*-vxworks constraint should run on the 
system headers found in sysroot, shouldn't they?  And this should be 
done *before* libgcc is built, as libgcc runs on the target and so needs 
fixed target includes, right?  If so, and I have run genfixes, and the 
make check appears to be fine, then why is the fix not getting applied?

Again, thanks for all your help,

Robert Mason

Re: Why is fixincludes not doing anything?

[rbmj]

On 05/25/2012 07:18 PM, Ian Lance Taylor wrote:
> rbmj<rbmj@verizon.net>  writes:
>
>> Maybe that's the error:
>>
>> ./gcc/xgcc -print-sysroot-headers-suffix
>> xgcc: fatal error: not configured with sysroot headers suffix
>>
>> xgcc is the compiler in question right?  . is the build directory.  I
>> believe xgcc is the compiler that compiles all of the cross targets
>> (lib*).
> Yes.
>
>> 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.
>
> Otherwise, I'm not entirely sure.  The Makefile rules for running
> fixincludes are pretty tangled.
OK, so even with --sysroot, I get the following:
$ ./gcc/xgcc -print-sysroot
/opt/powerpc-wrs-vxworks
$ ./gcc/xgcc -print-sysroot-headers-suffix
xgcc: fatal error: not configured with sysroot headers suffix
compilation terminated.

Also, looking at build-x86_64-unknown-linux-gnu/fixincludes/fixinc.sh:
#!/bin/sh
exit 0

And re your earlier comment about the t-* files:
[in gcc/config] $ find | xargs grep STMP_FIXINC
./i386/t-cygming:STMP_FIXINC=stmp-fixinc
./mips/t-sdemtk:STMP_FIXINC = stmp-sdefixinc

AHA!

Looking at mkfixinc.sh:

case $machine in
     i?86-*-cygwin* | \
     i?86-*-mingw32* | \
     x86_64-*-mingw32* | \
     i?86-*-interix* | \
     *-*-vxworks* | \
     powerpc-*-eabisim* | \
     powerpc-*-eabi*    | \
     powerpc-*-rtems*   | \
     powerpcle-*-eabisim* | \
     powerpcle-*-eabi* )
     #  IF there is no include fixing,
     #  THEN create a no-op fixer and exit
     (echo "#! /bin/sh" ; echo "exit 0" ) > ${target}
         ;;

     *)
     cat < ${srcdir}/fixinc.in > ${target} || exit 1
     ;;
esac

That looks like the problem.

So, new question- why is vxWorks disabled from include fixing?

Robert Mason

Re: Why is fixincludes not doing anything?

[Ian Lance Taylor]

rbmj <rbmj@verizon.net> writes:

> Looking at mkfixinc.sh:
>
> case $machine in
>     i?86-*-cygwin* | \
>     i?86-*-mingw32* | \
>     x86_64-*-mingw32* | \
>     i?86-*-interix* | \
>     *-*-vxworks* | \
>     powerpc-*-eabisim* | \
>     powerpc-*-eabi*    | \
>     powerpc-*-rtems*   | \
>     powerpcle-*-eabisim* | \
>     powerpcle-*-eabi* )
>     #  IF there is no include fixing,
>     #  THEN create a no-op fixer and exit
>     (echo "#! /bin/sh" ; echo "exit 0" ) > ${target}
>         ;;
>
>     *)
>     cat < ${srcdir}/fixinc.in > ${target} || exit 1
>     ;;
> esac
>
> That looks like the problem.
>
> So, new question- why is vxWorks disabled from include fixing?

Good job tracking it down.

This is the patch:

http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00361.html

This is where it was approved:

http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00717.html

So now at least you have some people to ask.

Ian

Re: Why is fixincludes not doing anything?

[rbmj]

[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]

On 05/29/2012 06:48 PM, Ian Lance Taylor wrote:
> Good job tracking it down.
>
> This is the patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00361.html
>
> This is where it was approved:
>
> http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00717.html
>
> So now at least you have some people to ask.
I got the same issues as noted in the patch message about CPU.  However, 
just disabling fixincludes outright seems like a kludgey way to solve 
the problem.  I think it would be better (less bad?) to only disable the 
machine_name fix.

As a bit of a hack (though IMHO less of a hack then just disabling the 
whole system), I disabled the machine_name fix and re-enabled 
fixincludes with the attached patch, as I *need* to change the header 
files to get gcc targeting vxworks to compile, and these are not changes 
that are easily accommodated with changes to GCC.  If I apply the patch, 
regenerate gcc/configure, and do a clean build fixincludes runs and the 
build finishes without errors.  The configure/build also works for a 
normal, native build.  Should I submit to -patches, in anticipation of 
submitting the hacks necessary to get a build without manually patching 
the headers?  Or is this not the right approach?

Thanks!

Robert Mason

[-- Attachment #2: 01-machine-name.patch --]
[-- Type: text/x-patch, Size: 2798 bytes --]

From fb4b751fd076adfc1596720bee4b4ba49f908431 Mon Sep 17 00:00:00 2001
From: rbmj <rbmj@verizon.net>
Date: Wed, 30 May 2012 08:16:57 -0400
Subject: [PATCH 1/5] Add ability to skip the machine_name fixincludes fix.

On some platforms, machine_name is overzealous, or even breaks things.
This patch adds the functionality to skip the machine_name 'fix' by
giving it an empty macro list.

gcc/configure: Regenerate
---
 fixincludes/mkfixinc.sh |    1 -
 gcc/Makefile.in         |   15 +++++++++++----
 gcc/configure.ac        |   14 ++++++++++++++
 3 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/fixincludes/mkfixinc.sh b/fixincludes/mkfixinc.sh
index 89e8ab7..6653fed 100755
--- a/fixincludes/mkfixinc.sh
+++ b/fixincludes/mkfixinc.sh
@@ -15,7 +15,6 @@ case $machine in
     i?86-*-mingw32* | \
     x86_64-*-mingw32* | \
     i?86-*-interix* | \
-    *-*-vxworks* | \
     powerpc-*-eabisim* | \
     powerpc-*-eabi*    | \
     powerpc-*-rtems*   | \
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 7b61b71..3534cd8 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -245,6 +245,9 @@ LINKER_FLAGS = $(CFLAGS)
 endif
 endif
 
+# Whether or not to run the machine_name fixincludes fix
+SKIP_MACHINE_NAME_FIX = @skip_machine_name_fix@
+
 # -------------------------------------------
 # Programs which operate on the build machine
 # -------------------------------------------
@@ -4129,10 +4132,14 @@ install-gcc-tooldir:
 
 macro_list: s-macro_list; @true
 s-macro_list : $(GCC_PASSES)
-	echo | $(GCC_FOR_TARGET) -E -dM - | \
-	  sed -n -e 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p' \
-		 -e 's/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \
-	  sort -u > tmp-macro_list
+	@if test "$(SKIP_MACHINE_NAME_FIX)" != "yes" ; then \
+		echo | $(GCC_FOR_TARGET) -E -dM - | \
+			sed -n -e 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p' \
+				-e 's/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \
+			sort -u > tmp-macro_list ; \
+	else \
+		echo > tmp-macro_list ; \
+	fi
 	$(SHELL) $(srcdir)/../move-if-change tmp-macro_list macro_list
 	$(STAMP) s-macro_list
 
diff --git a/gcc/configure.ac b/gcc/configure.ac
index a3a4038..d399ecc 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -5140,6 +5140,20 @@ if test x"${LINKER_HASH_STYLE}" != x; then
                                          [The linker hash style])
 fi
 
+# Check whether to enable the fixincludes machine_name hack on this platform
+case "${target}" in
+    *-*-vxworks*)
+        skip_machine_name_fix="yes"
+        ;;
+    *)
+        # Note that some platforms have fixincludes disabled by default so
+        # this will make no difference
+        skip_machine_name_fix="no"
+        ;;
+esac
+AC_SUBST(skip_machine_name_fix)
+
+
 # Configure the subdirectories
 # AC_CONFIG_SUBDIRS($subdirs)
 
-- 
1.7.5.4

Re: Why is fixincludes not doing anything?

[Ian Lance Taylor]

rbmj <rbmj@verizon.net> writes:

> As a bit of a hack (though IMHO less of a hack then just disabling the
> whole system), I disabled the machine_name fix and re-enabled
> fixincludes with the attached patch, as I *need* to change the header
> files to get gcc targeting vxworks to compile, and these are not
> changes that are easily accommodated with changes to GCC.  If I apply
> the patch, regenerate gcc/configure, and do a clean build fixincludes
> runs and the build finishes without errors.  The configure/build also
> works for a normal, native build.  Should I submit to -patches, in
> anticipation of submitting the hacks necessary to get a build without
> manually patching the headers?  Or is this not the right approach?

Yes, please do send to gcc-patches.  You should CC
nathan@codesourcery.com, who is the maintainer of the GCC VxWorks port.

Thanks!

Ian