From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul D. Smith" To: karuottu@freenet.hut.fi Cc: crossgcc@sourceware.cygnus.com Subject: Re: Building GCC 2.95.2 for VxWorks (powerpc) Date: Sun, 01 Apr 2001 00:00:00 -0000 Message-ID: <14931.20047.409084.918168@lemming.engeast.baynetworks.com> References: <14930.54708.649384.110329@lemming.engeast.baynetworks.com> <3A530F5E.F2629F2E@luukku.com> X-SW-Source: 2001-q1/msg00014.html Message-ID: <20010401000000.OB445bi9NMJYRTusEyQ35FYZhqwT_T64pJO-oYVE9Lw@z> %% Kai Ruottu 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 first that it works. I got the same effect by adding an #include 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 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