RE: Building GCC 2.95.2 for VxWorks (powerpc)

RE: Building GCC 2.95.2 for VxWorks (powerpc)

[David Korn]

      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

RE: Building GCC 2.95.2 for VxWorks (powerpc)

[David Korn]

      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

Re: Building GCC 2.95.2 for VxWorks (powerpc)

[Ryan Maples]

Paul,

I have this same setup and have developed a shell script to build the tool set for
me.

I have defined a directory structure as such:
[src]$ ls -l vxbuild
vxbuild:
gnu-chain
my_config

vxbuild/gnu-chain:
build           -- the docs suggest building the tool chain in a directory separate
from the source
src              -- unpacked sources

vxbuild/gnu-chain/build:
binutils-2.10.1
gcc-2.95.2

vxbuild/gnu-chain/build/binutils-2.10.1:

vxbuild/gnu-chain/build/gcc-2.95.2:

vxbuild/gnu-chain/src:
binutils-2.10.1
gcc-2.95.2

vxbuild/my_config:
vxppc_bld.sh

My script requires that the sources be unpacked in the "gnu-chain/src" directory.
The shell script is named
"vxppc_bld.sh" and exists in the "my_config" directory.  You have to edit the
script once you get it to
change a few variables:

1) modify BINUT_DIR to match the unpacked source directory of the binutils.  I have
it defined as
binutils-2.10.1

2) modify GCC_DIR to match the unpacked source directory of the gcc you are using.
I have it defined
as gcc-2.95.2

3) next modify the MY_HOST variable to match the machine you are running on.  I
have it defined as
i586-pc-linux-gnu

4) modify the MY_TARGET variable to match the architecture you are targeting with
you cross
development tools.  I had it defined as powerpc-wrs-vxworks.

5) modify the BASE_DIR variable to where you have setup the aforementioned
directory structure.  I
have set it to /src/vxbuild

6) finally modify the INSTALL_DIR and VXW_HDRS variables to point at your
installation of
VxWorks.  I have VxWorks 5.3.1 and it is installed at /usr/wind.  Therefore I have
the INSTALL_DIR
setup so that my linux tool set is rooted in the same place as the one for the
SPARC which is
/usr/wind/host/$MY_HOST.  The VXW_HDRS is setup to copy the needed VxWorks header
files from
/usr/wind/target/h.

It takes a lot of setup time but, if you make a mistake all you have to do is edit
the file and run it again.  As
opposed to typing it all in at the command line.  I'm sorry if this seems verbose,
but I am trying to be
precise.  I would be glad to try and answer/clarify any questions you have.  I am
running stock RedHat
6.1.  Note. The --with-newlib does not really install or use newlib.  As you can
see by the fact that the
script does not build or install the software.  The software sources for newlib do
not even exist on the
machine I build on.  The C++ compiler has built successfully many times but.  I
have never tried to
cross compile C++ code for my target.  Also, when compiling C source code for my
target the
preprocessor gives warnings of redefined preprocessor directives.  Even with these
warnings the code
works on the target.

Hope that helps,

    Ryan Maples

Here is the script:

[my_config]$ cat vxppc_bld.sh
#!/bin/bash
#
# Build Script for VxWorks dev tools under linux
#
#
########################################################################


#
# Define where all the pieces are and where they
# they are going to
########################################################################
BINUT_DIR=binutils-2.10.1
GCC_DIR=gcc-2.95.2
GDB_DIR=insight+dejagnu-20000428
MY_HOST=i586-pc-linux-gnu
MY_TARGET=powerpc-wrs-vxworks

BASE_DIR=/src/vxbuild
TOOLS_DIR=$BASE_DIR/gnu-chain
BUILD_DIR=$TOOLS_DIR/build
SRC_DIR=$TOOLS_DIR/src
MY_CONFIG=$BASE_DIR/my_config

INSTALL_DIR=/usr/wind/host/$MY_HOST
VXW_HDRS=/usr/wind/target/h


#
# Now Build the tools
########################################################################

# Build binutils
mkdir -p $BUILD_DIR/$BINUT_DIR
cd $BUILD_DIR/$BINUT_DIR
$SRC_DIR/$BINUT_DIR/configure -v \
 --prefix=$INSTALL_DIR \
 --exec-prefix=$INSTALL_DIR \
 --target=$MY_TARGET 2>&1 | tee configure.out

make -w all install 2>&1 | tee make.out

# Set path so that binutils for the target can be found
export PATH=$INSTALL_DIR/bin:$PATH

# Build gcc
mkdir -p $BUILD_DIR/$GCC_DIR
cd $BUILD_DIR/$GCC_DIR
$SRC_DIR/$GCC_DIR/configure -v \
 --prefix=$INSTALL_DIR \
 --exec-prefix=$INSTALL_DIR \
 --with-gnu-as --with-gnu-ld --with-newlib \
 --with-headers=$VXW_HDRS \
 --target=$MY_TARGET 2>&1 | tee configure.out

make -w all-gcc install-gcc LANGUAGES="c c++ java" 2>&1 | tee make.out

## Build gdb
#cd $BUILD_DIR/$GDB_DIR
#$SRC_DIR/$GDB_DIR/configure -v \
# --prefix=$INSTALL_DIR/$MY_HOST \
# --exec-prefix=$INSTALL_DIR/$MY_HOST \
# --target=$MY_TARGET 2>&1 | tee configure.out
#
## --prefix=$INSTALL_DIR/H-$MY_HOST \
#make -w all install 2>&1 | tee make.out

#
# That's it...
########################################################################






"Paul D. Smith" wrote:

> I have VxWorks 5.3.1, with GCC 2.7.2 with host Solaris and target
> PowerPC (PPC603, or powerpc-eabi).  I do not have the source from WRS
> for this version of GCC; I can't find anyone at WRS who will tell me how
> to get it :-/.  I'm still trying.
>
> Anyway, I need to build GCC 2.95.2 for this same target, but on host
> Linux instead of Solaris.
>
> I've checked the mailing list archives, the crossgcc FAQ, and GCC site's
> instructions, etc. but I'm still having troubles.
>
> I built and installed binutils 2.10.1 (--target=powerpc-wrs-vxworks) and
> that went fine.
>
> Then I tried to build GCC 2.95.2.  I don't want to use newlib, I want to
> use the stuff from WRS--is this possible?
>
> 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.
>
> Then I configured it like this:
>
>   $ ../gcc-2.95.2/configure --target=powerpc-wrs-vxworks \
>          --enable-languages=c,c++ --enable-version-specific-runtime-libs
>          --with-gnu-as --with-gnu-ld --prefix=$prefix
>
> That seemed to work.
>
> I ran "make", and I hit the failure in fdmatch, etc. which I found
> referenced in Tony Farrell's message to this list of 20 Jul 2000,
> subject "Notes on building gcc-2.95.2 for VxWorks 5.2, 68k", and fixed
> it as recommended there, by adding an #include <types/vxTypesOld.h>.
>
> 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'
>   ../../../gcc-2.95.2/libio/iovfprintf.c:305: parse error before `int'
>   ../../../gcc-2.95.2/libio/iovfprintf.c:346: parse error before `int'
>   ../../../gcc-2.95.2/libio/iovfprintf.c:355: parse error before `long'
>   ../../../gcc-2.95.2/libio/iovfprintf.c:369: parse error before `double'
>   ../../../gcc-2.95.2/libio/iovfprintf.c:419: parse error before `long'
>   ../../../gcc-2.95.2/libio/iovfprintf.c:429: parse error before `unsigned'
>   ../../../gcc-2.95.2/libio/iovfprintf.c:441: parse error before `void'
>   ../../../gcc-2.95.2/libio/iovfprintf.c:447: parse error before `char'
>   ../../../gcc-2.95.2/libio/iovfprintf.c:471: parse error before `unsigned'
>   ../../../gcc-2.95.2/libio/iovfprintf.c:476: parse error before `unsigned'
>
> These apparently correspond to uses of va_arg()!
>
> Note I need both C _and_ C++, so I can't just punt libio.
>
> It seems to be a Very Bad Thing if stdarg.h is not set up correctly for
> this system, somehow!
>
> I've actually since tried building this same set of code in the same way
> on a Solaris (2.7) host instead of Linux, and it fails with the same
> errors there as well.
>
> Can anyone point out where I may have gone wrong, or what I can do to
> fix or further investigate this problem?
>
> Thanks...!
>
> --
> -------------------------------------------------------------------------------
>  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


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

Re: Building GCC 2.95.2 for VxWorks (powerpc)

[Kai Ruottu]

"Paul D. Smith" wrote:
> 
> I have VxWorks 5.3.1, with GCC 2.7.2 with host Solaris and target
> PowerPC (PPC603, or powerpc-eabi).  I do not have the source from WRS
> for this version of GCC; I can't find anyone at WRS who will tell me how
> to get it :-/.  I'm still trying.
> 
> Anyway, I need to build GCC 2.95.2 for this same target, but on host
> Linux instead of Solaris.
>
> Then I tried to build GCC 2.95.2.  I don't want to use newlib, I want to
> use the stuff from WRS--is this possible?

 Not possible but obligatory... The only reason to try newlib could be
when there aren't any original target libs and headers at all...
 
> 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.

 Making a copy would have been better, keeping the originals untouched.
Putting them in 'sys-include' enables the header fixing, but this doesn't
mean removing or renaming any original headers, although this case needs
also these things...
 
> 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'

 The VxWorks headers are a mess where the old gcc-2.7.2 C++ headers are
mixed with the VxWorks standard C headers. Cannot understand any reason
for this mess, every other GCC keeps the standard C headers and the version-
specific C++ headers in separate directories...

 So your first job is to purify the VxWorks headers by removing all the
C++ headers in them. That's why the copies could be much better... How to
recognize the C++ headers is then the problem. If you have an installed
'normal' gcc-2.7.2.x, the C++ headers are in '/usr/lib/g++-include' (Linux),
if a gcc-2.95.2, in '/usr/include/g++-3' (Linux). Making a printed list
of them and removing all the headers seen in the list from the VxWorks
headers, is one solution for the recognition-problem. Instructions about
"How-To purify the standard VxWorks C-headers from all C++-garbage" could
be a useful document in the archive of this list...

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

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

Building GCC 2.95.2 for VxWorks (powerpc)

[Paul D. Smith]

I have VxWorks 5.3.1, with GCC 2.7.2 with host Solaris and target
PowerPC (PPC603, or powerpc-eabi).  I do not have the source from WRS
for this version of GCC; I can't find anyone at WRS who will tell me how
to get it :-/.  I'm still trying.

Anyway, I need to build GCC 2.95.2 for this same target, but on host
Linux instead of Solaris.

I've checked the mailing list archives, the crossgcc FAQ, and GCC site's
instructions, etc. but I'm still having troubles.

I built and installed binutils 2.10.1 (--target=powerpc-wrs-vxworks) and
that went fine.

Then I tried to build GCC 2.95.2.  I don't want to use newlib, I want to
use the stuff from WRS--is this possible?

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.

Then I configured it like this:

  $ ../gcc-2.95.2/configure --target=powerpc-wrs-vxworks \
         --enable-languages=c,c++ --enable-version-specific-runtime-libs
         --with-gnu-as --with-gnu-ld --prefix=$prefix

That seemed to work.

I ran "make", and I hit the failure in fdmatch, etc. which I found
referenced in Tony Farrell's message to this list of 20 Jul 2000,
subject "Notes on building gcc-2.95.2 for VxWorks 5.2, 68k", and fixed
it as recommended there, by adding an #include <types/vxTypesOld.h>.

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'
  ../../../gcc-2.95.2/libio/iovfprintf.c:305: parse error before `int'
  ../../../gcc-2.95.2/libio/iovfprintf.c:346: parse error before `int'
  ../../../gcc-2.95.2/libio/iovfprintf.c:355: parse error before `long'
  ../../../gcc-2.95.2/libio/iovfprintf.c:369: parse error before `double'
  ../../../gcc-2.95.2/libio/iovfprintf.c:419: parse error before `long'
  ../../../gcc-2.95.2/libio/iovfprintf.c:429: parse error before `unsigned'
  ../../../gcc-2.95.2/libio/iovfprintf.c:441: parse error before `void'
  ../../../gcc-2.95.2/libio/iovfprintf.c:447: parse error before `char'
  ../../../gcc-2.95.2/libio/iovfprintf.c:471: parse error before `unsigned'
  ../../../gcc-2.95.2/libio/iovfprintf.c:476: parse error before `unsigned'

These apparently correspond to uses of va_arg()!

Note I need both C _and_ C++, so I can't just punt libio.

It seems to be a Very Bad Thing if stdarg.h is not set up correctly for
this system, somehow!

I've actually since tried building this same set of code in the same way
on a Solaris (2.7) host instead of Linux, and it fails with the same
errors there as well.

Can anyone point out where I may have gone wrong, or what I can do to
fix or further investigate this problem?

Thanks...!

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

Re: Building GCC 2.95.2 for VxWorks (powerpc)

[Paul D. Smith]

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

Re: Building GCC 2.95.2 for VxWorks (powerpc)

[Paul D. Smith]

%% Ryan Maples <rmaples@sigint.com> writes:

  rm> I have this same setup and have developed a shell script to build
  rm> the tool set for me.

Cool.  I'll take a look at your script; offhand it doesn't seem much
different than what I did except for the --with-newlib stuff.

I was able to get things to build, although I had to hack a few files
(see my other posts).  I will almost definitely end up rebuilding the
cross-compiler again, though, to clean things up.

Were you able to build without changing _any_ files, including the
fdmatch bug and the collect2 stuff, and have it all work?

  rm> 6.1.  Note. The --with-newlib does not really install or use
  rm> newlib.  As you can see by the fact that the script does not build
  rm> or install the software.  The software sources for newlib do not
  rm> even exist on the machine I build on.

Then can you tell me why you include --with-newlib?

What does this flag do for the configure and why is it used/needed?

That would be most helpful.  Thanks!

  rm> The C++ compiler has built successfully many times but I have
  rm> never tried to cross compile C++ code for my target.

Ah, this probably explains why you don't need to modify the collect2
stuff.  Only if you did use C++, would you run into this problem.

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

Re: Building GCC 2.95.2 for VxWorks (powerpc)

[Paul D. Smith]

%% Ryan Maples <rmaples@sigint.com> writes:

  rm> I have this same setup and have developed a shell script to build
  rm> the tool set for me.

Cool.  I'll take a look at your script; offhand it doesn't seem much
different than what I did except for the --with-newlib stuff.

I was able to get things to build, although I had to hack a few files
(see my other posts).  I will almost definitely end up rebuilding the
cross-compiler again, though, to clean things up.

Were you able to build without changing _any_ files, including the
fdmatch bug and the collect2 stuff, and have it all work?

  rm> 6.1.  Note. The --with-newlib does not really install or use
  rm> newlib.  As you can see by the fact that the script does not build
  rm> or install the software.  The software sources for newlib do not
  rm> even exist on the machine I build on.

Then can you tell me why you include --with-newlib?

What does this flag do for the configure and why is it used/needed?

That would be most helpful.  Thanks!

  rm> The C++ compiler has built successfully many times but I have
  rm> never tried to cross compile C++ code for my target.

Ah, this probably explains why you don't need to modify the collect2
stuff.  Only if you did use C++, would you run into this problem.

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

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

Re: Building GCC 2.95.2 for VxWorks (powerpc)

[Ryan Maples]

Paul,

I have this same setup and have developed a shell script to build the tool set for
me.

I have defined a directory structure as such:
[src]$ ls -l vxbuild
vxbuild:
gnu-chain
my_config

vxbuild/gnu-chain:
build           -- the docs suggest building the tool chain in a directory separate
from the source
src              -- unpacked sources

vxbuild/gnu-chain/build:
binutils-2.10.1
gcc-2.95.2

vxbuild/gnu-chain/build/binutils-2.10.1:

vxbuild/gnu-chain/build/gcc-2.95.2:

vxbuild/gnu-chain/src:
binutils-2.10.1
gcc-2.95.2

vxbuild/my_config:
vxppc_bld.sh

My script requires that the sources be unpacked in the "gnu-chain/src" directory.
The shell script is named
"vxppc_bld.sh" and exists in the "my_config" directory.  You have to edit the
script once you get it to
change a few variables:

1) modify BINUT_DIR to match the unpacked source directory of the binutils.  I have
it defined as
binutils-2.10.1

2) modify GCC_DIR to match the unpacked source directory of the gcc you are using.
I have it defined
as gcc-2.95.2

3) next modify the MY_HOST variable to match the machine you are running on.  I
have it defined as
i586-pc-linux-gnu

4) modify the MY_TARGET variable to match the architecture you are targeting with
you cross
development tools.  I had it defined as powerpc-wrs-vxworks.

5) modify the BASE_DIR variable to where you have setup the aforementioned
directory structure.  I
have set it to /src/vxbuild

6) finally modify the INSTALL_DIR and VXW_HDRS variables to point at your
installation of
VxWorks.  I have VxWorks 5.3.1 and it is installed at /usr/wind.  Therefore I have
the INSTALL_DIR
setup so that my linux tool set is rooted in the same place as the one for the
SPARC which is
/usr/wind/host/$MY_HOST.  The VXW_HDRS is setup to copy the needed VxWorks header
files from
/usr/wind/target/h.

It takes a lot of setup time but, if you make a mistake all you have to do is edit
the file and run it again.  As
opposed to typing it all in at the command line.  I'm sorry if this seems verbose,
but I am trying to be
precise.  I would be glad to try and answer/clarify any questions you have.  I am
running stock RedHat
6.1.  Note. The --with-newlib does not really install or use newlib.  As you can
see by the fact that the
script does not build or install the software.  The software sources for newlib do
not even exist on the
machine I build on.  The C++ compiler has built successfully many times but.  I
have never tried to
cross compile C++ code for my target.  Also, when compiling C source code for my
target the
preprocessor gives warnings of redefined preprocessor directives.  Even with these
warnings the code
works on the target.

Hope that helps,

    Ryan Maples

Here is the script:

[my_config]$ cat vxppc_bld.sh
#!/bin/bash
#
# Build Script for VxWorks dev tools under linux
#
#
########################################################################


#
# Define where all the pieces are and where they
# they are going to
########################################################################
BINUT_DIR=binutils-2.10.1
GCC_DIR=gcc-2.95.2
GDB_DIR=insight+dejagnu-20000428
MY_HOST=i586-pc-linux-gnu
MY_TARGET=powerpc-wrs-vxworks

BASE_DIR=/src/vxbuild
TOOLS_DIR=$BASE_DIR/gnu-chain
BUILD_DIR=$TOOLS_DIR/build
SRC_DIR=$TOOLS_DIR/src
MY_CONFIG=$BASE_DIR/my_config

INSTALL_DIR=/usr/wind/host/$MY_HOST
VXW_HDRS=/usr/wind/target/h


#
# Now Build the tools
########################################################################

# Build binutils
mkdir -p $BUILD_DIR/$BINUT_DIR
cd $BUILD_DIR/$BINUT_DIR
$SRC_DIR/$BINUT_DIR/configure -v \
 --prefix=$INSTALL_DIR \
 --exec-prefix=$INSTALL_DIR \
 --target=$MY_TARGET 2>&1 | tee configure.out

make -w all install 2>&1 | tee make.out

# Set path so that binutils for the target can be found
export PATH=$INSTALL_DIR/bin:$PATH

# Build gcc
mkdir -p $BUILD_DIR/$GCC_DIR
cd $BUILD_DIR/$GCC_DIR
$SRC_DIR/$GCC_DIR/configure -v \
 --prefix=$INSTALL_DIR \
 --exec-prefix=$INSTALL_DIR \
 --with-gnu-as --with-gnu-ld --with-newlib \
 --with-headers=$VXW_HDRS \
 --target=$MY_TARGET 2>&1 | tee configure.out

make -w all-gcc install-gcc LANGUAGES="c c++ java" 2>&1 | tee make.out

## Build gdb
#cd $BUILD_DIR/$GDB_DIR
#$SRC_DIR/$GDB_DIR/configure -v \
# --prefix=$INSTALL_DIR/$MY_HOST \
# --exec-prefix=$INSTALL_DIR/$MY_HOST \
# --target=$MY_TARGET 2>&1 | tee configure.out
#
## --prefix=$INSTALL_DIR/H-$MY_HOST \
#make -w all install 2>&1 | tee make.out

#
# That's it...
########################################################################






"Paul D. Smith" wrote:

> I have VxWorks 5.3.1, with GCC 2.7.2 with host Solaris and target
> PowerPC (PPC603, or powerpc-eabi).  I do not have the source from WRS
> for this version of GCC; I can't find anyone at WRS who will tell me how
> to get it :-/.  I'm still trying.
>
> Anyway, I need to build GCC 2.95.2 for this same target, but on host
> Linux instead of Solaris.
>
> I've checked the mailing list archives, the crossgcc FAQ, and GCC site's
> instructions, etc. but I'm still having troubles.
>
> I built and installed binutils 2.10.1 (--target=powerpc-wrs-vxworks) and
> that went fine.
>
> Then I tried to build GCC 2.95.2.  I don't want to use newlib, I want to
> use the stuff from WRS--is this possible?
>
> 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.
>
> Then I configured it like this:
>
>   $ ../gcc-2.95.2/configure --target=powerpc-wrs-vxworks \
>          --enable-languages=c,c++ --enable-version-specific-runtime-libs
>          --with-gnu-as --with-gnu-ld --prefix=$prefix
>
> That seemed to work.
>
> I ran "make", and I hit the failure in fdmatch, etc. which I found
> referenced in Tony Farrell's message to this list of 20 Jul 2000,
> subject "Notes on building gcc-2.95.2 for VxWorks 5.2, 68k", and fixed
> it as recommended there, by adding an #include <types/vxTypesOld.h>.
>
> 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'
>   ../../../gcc-2.95.2/libio/iovfprintf.c:305: parse error before `int'
>   ../../../gcc-2.95.2/libio/iovfprintf.c:346: parse error before `int'
>   ../../../gcc-2.95.2/libio/iovfprintf.c:355: parse error before `long'
>   ../../../gcc-2.95.2/libio/iovfprintf.c:369: parse error before `double'
>   ../../../gcc-2.95.2/libio/iovfprintf.c:419: parse error before `long'
>   ../../../gcc-2.95.2/libio/iovfprintf.c:429: parse error before `unsigned'
>   ../../../gcc-2.95.2/libio/iovfprintf.c:441: parse error before `void'
>   ../../../gcc-2.95.2/libio/iovfprintf.c:447: parse error before `char'
>   ../../../gcc-2.95.2/libio/iovfprintf.c:471: parse error before `unsigned'
>   ../../../gcc-2.95.2/libio/iovfprintf.c:476: parse error before `unsigned'
>
> These apparently correspond to uses of va_arg()!
>
> Note I need both C _and_ C++, so I can't just punt libio.
>
> It seems to be a Very Bad Thing if stdarg.h is not set up correctly for
> this system, somehow!
>
> I've actually since tried building this same set of code in the same way
> on a Solaris (2.7) host instead of Linux, and it fails with the same
> errors there as well.
>
> Can anyone point out where I may have gone wrong, or what I can do to
> fix or further investigate this problem?
>
> Thanks...!
>
> --
> -------------------------------------------------------------------------------
>  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


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

Re: Building GCC 2.95.2 for VxWorks (powerpc)

[Paul D. Smith]

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

Re: Building GCC 2.95.2 for VxWorks (powerpc)

[Kai Ruottu]

"Paul D. Smith" wrote:
> 
> I have VxWorks 5.3.1, with GCC 2.7.2 with host Solaris and target
> PowerPC (PPC603, or powerpc-eabi).  I do not have the source from WRS
> for this version of GCC; I can't find anyone at WRS who will tell me how
> to get it :-/.  I'm still trying.
> 
> Anyway, I need to build GCC 2.95.2 for this same target, but on host
> Linux instead of Solaris.
>
> Then I tried to build GCC 2.95.2.  I don't want to use newlib, I want to
> use the stuff from WRS--is this possible?

 Not possible but obligatory... The only reason to try newlib could be
when there aren't any original target libs and headers at all...
 
> 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.

 Making a copy would have been better, keeping the originals untouched.
Putting them in 'sys-include' enables the header fixing, but this doesn't
mean removing or renaming any original headers, although this case needs
also these things...
 
> 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'

 The VxWorks headers are a mess where the old gcc-2.7.2 C++ headers are
mixed with the VxWorks standard C headers. Cannot understand any reason
for this mess, every other GCC keeps the standard C headers and the version-
specific C++ headers in separate directories...

 So your first job is to purify the VxWorks headers by removing all the
C++ headers in them. That's why the copies could be much better... How to
recognize the C++ headers is then the problem. If you have an installed
'normal' gcc-2.7.2.x, the C++ headers are in '/usr/lib/g++-include' (Linux),
if a gcc-2.95.2, in '/usr/include/g++-3' (Linux). Making a printed list
of them and removing all the headers seen in the list from the VxWorks
headers, is one solution for the recognition-problem. Instructions about
"How-To purify the standard VxWorks C-headers from all C++-garbage" could
be a useful document in the archive of this list...

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

Building GCC 2.95.2 for VxWorks (powerpc)

[Paul D. Smith]

I have VxWorks 5.3.1, with GCC 2.7.2 with host Solaris and target
PowerPC (PPC603, or powerpc-eabi).  I do not have the source from WRS
for this version of GCC; I can't find anyone at WRS who will tell me how
to get it :-/.  I'm still trying.

Anyway, I need to build GCC 2.95.2 for this same target, but on host
Linux instead of Solaris.

I've checked the mailing list archives, the crossgcc FAQ, and GCC site's
instructions, etc. but I'm still having troubles.

I built and installed binutils 2.10.1 (--target=powerpc-wrs-vxworks) and
that went fine.

Then I tried to build GCC 2.95.2.  I don't want to use newlib, I want to
use the stuff from WRS--is this possible?

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.

Then I configured it like this:

  $ ../gcc-2.95.2/configure --target=powerpc-wrs-vxworks \
         --enable-languages=c,c++ --enable-version-specific-runtime-libs
         --with-gnu-as --with-gnu-ld --prefix=$prefix

That seemed to work.

I ran "make", and I hit the failure in fdmatch, etc. which I found
referenced in Tony Farrell's message to this list of 20 Jul 2000,
subject "Notes on building gcc-2.95.2 for VxWorks 5.2, 68k", and fixed
it as recommended there, by adding an #include <types/vxTypesOld.h>.

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'
  ../../../gcc-2.95.2/libio/iovfprintf.c:305: parse error before `int'
  ../../../gcc-2.95.2/libio/iovfprintf.c:346: parse error before `int'
  ../../../gcc-2.95.2/libio/iovfprintf.c:355: parse error before `long'
  ../../../gcc-2.95.2/libio/iovfprintf.c:369: parse error before `double'
  ../../../gcc-2.95.2/libio/iovfprintf.c:419: parse error before `long'
  ../../../gcc-2.95.2/libio/iovfprintf.c:429: parse error before `unsigned'
  ../../../gcc-2.95.2/libio/iovfprintf.c:441: parse error before `void'
  ../../../gcc-2.95.2/libio/iovfprintf.c:447: parse error before `char'
  ../../../gcc-2.95.2/libio/iovfprintf.c:471: parse error before `unsigned'
  ../../../gcc-2.95.2/libio/iovfprintf.c:476: parse error before `unsigned'

These apparently correspond to uses of va_arg()!

Note I need both C _and_ C++, so I can't just punt libio.

It seems to be a Very Bad Thing if stdarg.h is not set up correctly for
this system, somehow!

I've actually since tried building this same set of code in the same way
on a Solaris (2.7) host instead of Linux, and it fails with the same
errors there as well.

Can anyone point out where I may have gone wrong, or what I can do to
fix or further investigate this problem?

Thanks...!

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