On 11/1/2012 10:48 AM, Bruce Korb wrote:
Hi Robert,
On Thu, Nov 1, 2012 at 6:35 AM, rbmj wrote:
and now my patches will build on top of
trunk. Bruce, can you give steps on how to reproduce the error you
reported?
rm -rf gcc-bld gcc-ins
cp -l gcc-svn gcc-bld
pfx=$PWD/gcc-ins
cd gcc-bld
Hi Robert,
On Thu, Nov 1, 2012 at 6:35 AM, rbmj wrote:
> and now my patches will build on top of
> trunk. Bruce, can you give steps on how to reproduce the error you
> reported?
rm -rf gcc-bld gcc-ins
cp -l gcc-svn gcc-bld
pfx=$PWD/gcc-ins
cd gcc-bld
./configure --enable-languages=c,c++ --p
On 10/29/2012 10:07 PM, rbmj wrote:
I get a clean build on my end... no stdarg.h issues. Build
characteristics are given in the previous email.
On 10/29/2012 4:26 PM, rbmj wrote:
The build does eventually die in libstdc++-v3, but that's not due to
these changes (it gives me an internal compile
I get a clean build on my end... no stdarg.h issues. Build
characteristics are given in the previous email.
On 10/29/2012 4:26 PM, rbmj wrote:
The build does eventually die in libstdc++-v3, but that's not due to
these changes (it gives me an internal compiler error while compiling
complex_io.c
On 10/29/2012 12:53 PM, Bruce Korb wrote:
The first two patches I've applied. The remaining two are needed to fully
enable building the VxWorks flavor of GCC, but those bits affect parts
outside of fixincludes and there is some breakage somewhere.
All evidence seems to me to show fixincludes sti
The first two patches I've applied. The remaining two are needed to fully
enable building the VxWorks flavor of GCC, but those bits affect parts
outside of fixincludes and there is some breakage somewhere.
All evidence seems to me to show fixincludes still doing its thing correctly,
but somewhere
