RE: Building GCC 2.95.2 for VxWorks (powerpc)

[David Korn <dkorn at pixelpower dot com>]

      Hi guys, 

  This is something that I've been working on a lot myself lately. There's
quite a few issues:

> - 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... 

  All the headers that are put in sys-include get fixed and copied
into $builddir/gcc/include, so that's correct. The hack that put va_ stuff
into toolPpc.h was added by WRS as PPC/EABI varargs wasn't working 100%
in the main source tree at the time around 2.7.2.  The 'right' answer
would be to write new fixincs rules to sort the mess out, but I haven't
studied how that works yet. 

  Another problem is that WRS default makefiles don't use the fixed 
headers (that end up being installed in $prefix/lib/gcc-lib/$target/
$version/include) at all, so it would be necessary to either modify all
the makefiles (and the TCL scripts that auto-generate them), or to 
modify the original VxW headers to fix the problem there also.

  OTOH, I'm not sure why you want to build any of the gcc target libs
for VxWorks at all? Isn't it simplest to just use the library functions
from the OS, for which the WRS headers will provide the correct definitions?
What is the functionality that is needed from libio that the OS doesn't
provide? Does this in any way relate to the --enable-version-specific-
runtime-libs configure flag ? I never heard of this flag before, it would
be kind if one of you could tell me what it does.

>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...

  Hooray! I'm not crazy after all :-)

  There is another problem with 2.95.2, or rather there is a problem with
the 2.7.2-based libs that WRS supply, which is that double and long long
function arguments are aligned to 8-bytes in 2.95.2, but only 4 bytes in
2.7.2.  I'm currently testing a patch to the source code that should fix
this one.

  Finally, I'll also point out that the target flag "-mlongcall" is a WRS
patch to gcc that hasn't been ported back to the mainline.  This will be a
big problem if your target board has >32 meg of RAM.  I'm working on a
patch for this one too.  So far I've been talking about VxW patches with
others on the Gcc list from my home email address, so I'll subscribe
crossgcc from there and add it to any crossposts if you'd like ?

   happy new year,
        DaveK

-- 
The Boulder Pledge: "Under no circumstances will I ever purchase anything 
offered to me as the result of an unsolicited email message. Nor will I 
forward chain letters, petitions, mass mailings, or virus warnings to large 
numbers of others. This is my contribution to the survival of the online
community." 

>-----Original Message-----
>From: Kai Ruottu [mailto:kai.ruottu@luukku.com]
>Sent: 04 January 2001 09:07
>To: Paul D. Smith
>Cc: crossgcc@sourceware.cygnus.com
>Subject: Re: Building GCC 2.95.2 for VxWorks (powerpc)
>
>
>"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


>
> 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)
>




>
> - 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
>


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

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