This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[patch] prevent fixincludes from doing anything for VxWorks


Hello,

A cross build for powerpc-wrs-vxworks hosted on x86-linux
or sparc-solaris currently fails on

  .../vx-bld/./gcc/include/types/vxCpu.h:349:2:
  error: #error CPU is not defined correctly
  make[3]: *** [libgcc/./_fixunssfsi.o] Error 1

(binutils + system header files preinstalled in $prefix, then 
 configure --target=powerpc-wrs-vxworks --prefix=... --enable-languages=c
 && make)

This is caused by "fixincludes" applying "machine_name" to virtually
every system header file, adding '__' around instances of CPU/CPU_FAMILY
within #if expressions while gcc defines the bare names only:

   config/rs6000/vxworks.h
   <<
      #define TARGET_OS_CPP_BUILTINS()             \
	 ...
	 /* C89 namespace violation! */            \
	 builtin_define ("CPU_FAMILY=PPC");        \


      #define CPP_SPEC \
      "%{!DCPU=*:               \
	  %{mcpu=403 : -DCPU=PPC403  ; \                 
	    mcpu=405 : -DCPU=PPC405  ; \ 
   >>

>From past experience and discussions, my understanding is that the
best thing for VxWorks is a noop fixincludes process, as the system
header files of even moderately modern versions of VxWorks (say from
5.4) are supposed to be in the appropriate format already, and my
impression is that GCC is not quite setup to support older versions
at this stage.

Totally disabling fixincludes by adding a "STMP-FIXINC = " line in
e.g. config/t-vxworks is a bit too strong, as this prevents the creation
of syslimits.h, required while compiling libgcc.

The patch attached addresses this by adding an "*-*-vxworks*" entry to
the existing list forcing a noop process in mkfixinc.sh.

Whether it would better be specialized on a processor name basis is
not ckear to me. If not, the rules in inclhack.def could probably be
removed in addition.

Tested by checking that the build completes with the change, and that
the resulting compiler is at least basically functional.

The build actually needs another change to complete (missing arg in
calls to open from ssp.c), but this is totally unrelated to the
fixincludes matters.

Comments welcome,

Thanks in advance,

Olivier

--

2006-10-07  Olivier Hainque  <hainque@adacore.com>

	* fixincludes/mkfixinc.sh: Add "*-*-vxworks*" to the list of
	targets for which a no-op fixer is appropriate.








Attachment: vx-mkfixinc.dif
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]