Building GCC 2.95.2 for VxWorks (powerpc)

[Kai Ruottu]

"Paul D. Smith" wrote:
> 
>   kr> So your first job is to purify the VxWorks headers by removing all
>   kr> the C++ headers in them.
> 
> Or do you mean just deleting (rm'ing) all the C++ headers that are in
> the sys-include directory?

 Yes, that was what I meaned, no C++ headers mixed with the standard C
headers...
 
> Anyway, this doesn't seem to be the problem.

 But the operation wasn't vain, I forgot to say that the reason for this
is that during the build the target's standard headers, if in the
'$prefix/$target/include' will be searched first. And forgot that you
didn't have them there. When you have them in '$prefix/$target/sys-include',
they are now searched after the 'gcc/include' etc. mentioned in the other '-I'
options, then the natural GCC search order follows...

 Anyway the headers are more 'clean' now, although probably not causing any
problems with C++ compiles...

 The '-I$(build_tooldir)/include' or something in the GCC_FOR_TARGET command
line would have been the reason for the old C++ headers being found before
those coming with gcc-2.95.2. The '$prefix/$target/include' has been the place
for the installed target headers for a long time. So using instead the
'sys-include' can be some kind of work-around for the VxWorks mess, and I'm
starting to see some sanity in using it, although preferring these cleaner
methods...

 BTW, how it now finds any target headers at all? Did you pre-create the
'$prefix/lib/gcc-lib/$target/2.95.2' ?  I haven't yet got any information
whether the 'plain-vanilla' gcc-2.95.2 sources have the Cygnus relative
search paths (with those '../../../../' members) or not... What I know is
that the Win32-patches try to add or change the search paths and I installed
the patches a year and half ago into my gcc-2.95.x sources... The command
'./xgcc -print-search-dirs', made in the 'gcc' build-dir, will show the GCC's
built-in search paths (for programs and libs only, but who couldn't believe
the headers-ones being similar...)

> I compared a list of C++ headers from an old installation of GCC 2.7.2 I
> had and what's in the sys-include directory, and the only C++ headers
> that appeared in the sys-include directory were these:
> 
>   fstream.h
>   generic.h
>   iomanip.h
>   iostream.h
>   new.h
>   stdiostream.h
>   stream.h
>   strstream.h
>   vector.h
> 
> That's it.

 Fine, now we have a list for the old libstdc++-2.7.x headers among the
VxWorks headers...
 
> I'm not sure this is the problem here (although it may be a different
> problem).  The file that's being compiled is a C file (iovfprintf.c),
> not a C++ file, and the compile error appears to be that va_arg() is not
> being expanded at all.  The line of code in question (iovfprintf.c:292)
> is:
> 
>     if ((width = va_arg(ap, int)) >= 0)

 This didn't trigger any memories about seeing the same ever, so I can only
list a couple more as potential sources for problems:

 - both the VxWorks standard headers and the GCC sources include the headers
   'stdarg.h', 'stddef.h' and 'varargs.h'. Which ones to use ?  The VxWorks-
   specific ones, but for gcc-2.7.2 ?  Or the generic GCC ones ?  My bet would
   be the VxWorks-ones being the right, but they may need some fixing... Ok,
   the 'fixincludes' probably did quite a lot work with fixing the headers,
   but what are the 'stdarg.h','stddef.h' and 'varargs.h' in the 'gcc/include'
   during the build ? Are they the fixed VxWorks ones or the GCC ones ? If the
   GCC ones are there, they are probably found first, not the ones in the
   'sys-include'. Then they must be disabled somehow...

 - there was a problem with the generated '_G_config.h', it defining a thing
   which doesn't exist, the 'HAVE_PRINTF_FP'. Here is a clip from an earlier
   VxWorks-case:

-------------------------------------- clip --------------------------------- 
>> building (I changed the '#define HAVE_PRINTF_H  1' to be '0' and also the
>> next '#define' about outputting doubles or something...).
> 
> this file for the string 'HAVE_PRINTF_H' but it doesn't exist.
> But the string 'HAVE_PRINTF_FP' exists and this is the #define which I
> changed from 1 to 0. I also changed the
> #define HAVE_LONG_DOUBLE_IO form 1 to 0.
-------------------------------------- clip --------------------------------- 

 Ok, I could imagine the second being related to the 'iovfprintf.c' somehow...

Cheers, Kai



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com