Re: cross compiling for VxWorks

Re: cross compiling for VxWorks

[mike stump]

> From: Francis Michel <francis.michel@criltechnology.com>
> To: gcc@gcc.gnu.org
> Date: Fri, 3 Aug 2001 19:21:01 +0200

> I'm new (back) on this list, and I'm willing to use gcc for VxWorks.
> I'd like to know if someone is working on this port and maybe I
> could contribute.

I work on this target.

> Is there any interest at the moment in fixing the tools to generate
> working headers for this target ?

It is always good to improve the tools.  I think we are always
interested in it.

> The first problem is an inconsistency between the macros
> CPU/CPU_FAMILY and the generated gcc.specs.

?

> Where should I start ?

At the first thing that doesn't work that you want to fix?

I have a large sent of patches against an older gcc that we work with
internally here.  I happy to send them out to you, if they'd help you.

Re: cross compiling for VxWorks

[Francis Michel]

> I have a large sent of patches against an older gcc that we work with
> internally here.  I happy to send them out to you, if they'd help you.

Yep,
I've run a simple java Hello world on my ppc-vxw target.
There are stil lots of unimplemented features, specially I have
not even tried to compile the GC.

Now I'll try to clean the environnement and make the tool generate
without manual interventions, starting with the C-compiler.

About these patches, what's their purpose ? and why aren't they integrated
in CVS ?? And of course I'd like to see them, whatever version they may be 
against.

Now my first problems are with fixincludes and configure. I have to edit a 
few things by hand before being able to compile libgcc.
genfixes scans specs and generates substitutions for all defines (not starting
with '_'). For example if specs say -DCPU=xxxx, genfixes and fixincludes
will substitue any occurrence of "CPU" with "__CPU__" in headers. But when
compiling, specs stil define CPU which is now of no interest if headers 
expect __CPU__. I don't understand what's the aim of this substitution. IMO, 
specs and headers should be left coherent, either by substituing in the 
headers AND the specs or by not substituing at all. An other solution would 
be to remove all CPU definition from the specs and let the user provide its 
own definition, just like it was done with old gcc versions (2.7.2-3).

What's your opinion ?

Nyny

Re: cross compiling for VxWorks

[mike stump]

> From: Francis Michel <francis.michel@criltechnology.com>
> To: gcc@gcc.gnu.org
> Date: Wed, 29 Aug 2001 11:09:27 +0200

> About these patches, what's their purpose?

Standard Answer 103: The purpose of a patch is to either fix a bug, or
add functionality that isn't already present.

> and why aren't they integrated in CVS ??

Standard Answer 429: Some need cleaning up, some need reenineering,
some need reintegration work done, some aren't needed any more, and
some just await some time for people to work on them.

> And of course I'd like to see them, whatever version they may be
> against.

I'll send them out directly to you.  At 1.5M for just the gcc sub
directory diffs, I don't want to burden everyone here.

> genfixes scans specs and generates substitutions for all defines
> (not starting with '_'). For example if specs say -DCPU=xxxx,

> What's your opinion ?

Hard problem, hard solution.  We get by, by always having a -DCPU on
the command line anyway.  This is part of the wrsGenMultilib
technology.

cross compiling for VxWorks

[Francis Michel]

Hi,
I'm new (back) on this list, and I'm willing to use gcc for VxWorks.
I'd like to know if someone is working on this port and maybe I could
contribute.

I've successfully built a 2.95.2 Solaris->VxW crosscompiler a while ago,
but now I'm planning to use java. The first step is to build a c and c++
compiler and a libstdc++.

I've built the c/c++ compilers and the library, they seem to work. But I had
to edit manually some files modified by fixinclude as well as the G_config.h.

Is there any interest at the moment in fixing the tools to generate working
headers for this target ?

The first problem is an inconsistency between the macros CPU/CPU_FAMILY
and the generated gcc.specs. Where should I start ?

[I'm building on linux and solaris for powerpc-vxworks]

fm