Re: Building GCC 2.95.2 for VxWorks (powerpc)

["Paul D. Smith" <pausmith@nortelnetworks.com>]

%% Kai Ruottu <kai.ruottu@luukku.com> writes:

Thanks for the speedy response!
 
  >> What I did was create $prefix/powerpc-wrs-vxworks/sys-include as a
  >> symlink pointing to the headers that came with the old GCC 2.7.2
  >> compiler for host Solaris.

  kr> Making a copy would have been better, keeping the originals untouched.

Well, I knew they couldn't be touched since I don't have write
permissions to them :).

But, I actually did make a copy instead, after a bit, since I needed to
modify the file for the fdmatch problem.
 
  >> Then libiberty built, but now I'm getting this error in
  >> libio/iovfprintf.c:
  >> 
  >> ../../../gcc-2.95.2/libio/iovfprintf.c: In function `_IO_vfprintf':
  >> ../../../gcc-2.95.2/libio/iovfprintf.c:292: parse error before `int'

  kr> So your first job is to purify the VxWorks headers by removing all
  kr> the C++ headers in them.

By this I assume you mean "remove any #includes of C++ headers from the
VxWorks headers"?

Or do you mean just deleting (rm'ing) all the C++ headers that are in
the sys-include directory?

Anyway, this doesn't seem to be the problem.

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.

I did an fgrep for these strings in all the other headers in sys-include
and none of these were included by any other header files.

I moved them, anyway, to a different temporary directory and tried to
rebuild, and it still failed the same way.

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)

I ran the same compile line with the -E option and this line appears
identically in the -E output, which is not right because va_arg() should
be a macro defined by stdarg.h, and be expanded by the preprocessor.

I looked at the rest of the -E output, and it appears that the problem
is to do with order of #include files.  In all the io*.c functions in
libio, the #include of stdarg.h comes _after_ some other,
system-specific header #include (such as libioP.h).

If I move the #include of stdarg.h to be the first thing in the .c file,
it compiles correctly.

The problem appears to be something to do with the arch/ppc/toolPpc.h
file that comes with VxWorks and is in my sys-include.  In that file
there's a section that begins like this:

  #ifdef _GNU_TOOL

  /* CYGNUS LOCAL Waiting for 2.7.1 to unfreeze */
  /* GNU C varargs support for the PowerPC with V.4 calling sequence */

    ...

then, it proceeds to do this:

  /* If this is for internal libc use, don't define anything but
     __gnuc_va_list.  */
  #define _STDARG_H

then it defines some macros as _ARCH_va_arg(), etc. instead of just
va_arg().  But, since it #defines _STDARG_H above, then later when the
compiler tries to include the "real" stdarg.h it is skipped because it's
wrapped in an #ifndef _STDARG_H to guard against multiple inclusions.

Unfortunately, that's not the only problem: I tried editing the
toolPpc.h to #undef _STDARG_H again after it was done being used, and
that solved most of the errors but not all of them; I still got one
compile error.

It's only if I actually move the #include of <stdarg.h> first that it
works.  I got the same effect by adding an #include <stdarg.h> to the
toolPpc.h file right after the #ifdef _GNU_TOOL above.

Now things seem to be compiling without generating any errors; we'll see
if the thing actually works... :-/.

I wonder if I don't have something wrong in my setup or config; I don't
see anyone else having this problem compiling GCC 2.95.2?  I notice most
other folks in the archives are building for m68k, etc.; maybe this
problem is specific to the PPC platform?

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@baynetworks.com>    HASMAT--HA Software Methods & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.

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