built-in declaration conflicts on SunOS & VxWorks targets.

Ian Lance Taylor ian@cygnus.com
Wed Feb 18 06:46:00 GMT 1998


   Date: Wed, 18 Feb 1998 09:17:44 -0500 (EST)
   From: "Brad M. Garcia" <bgarcia@fore.com>

   On Wed, 18 Feb 1998, Ian Lance Taylor wrote:

   > The normal way to fix this is to run fixincludes over the header
   > files.  That is supposed to take care of issues like this.  Did you do
   > that?

   Is this something that I need to do separately, or is it part of 
   the normal (configure/make all/make install) building process?
   If it's a separate step, then no, I didn't do it.

It is normally run automatically.  However, fixincludes does need to
be able to find your header files.  This is easy on a native
system--just look in /usr/include--but it is not so easy in a
cross-compilation environment.  As I recall, if you put your header
files in the directory ${exec_prefix}/${target_alias}/sys-include,
then fixincludes will run on them.

In the egcs release, the top level configure script should support a
--with-headers option.  If you configure with --with-headers=DIR,
where DIR is the directory where your VxWorks headers can be found,
then they will automatically be copied to the right directory and
fixincludes will run over them.

Note that I have not tested this with the egcs release.  However, I
hope this will point you to a better way to solve your problem than
changing the built in declarations within the compiler.

Look at the Cross Headers section of the documentation in the cross
compiling part of the manual for more information.

   And what exactly does running "fixincludes" do?  Does it create new
   header files?  Does it change gcc's internal declarations?

fixincludes creates new header files which are copies of your existing
header files modified to work with gcc, and to be more ANSI and POSIX
compliant.

Ian



More information about the Gcc-bugs mailing list