VxWorks specs vs fixincl, machname.h and machine_name_test

VxWorks specs vs fixincl, machname.h and machine_name_test

[Earl Chew]

I'm building a vxWorks PPC cross using gcc 3.4.2 and I'm trying
to understand how the machname fix is intended to work.

I've provided the compiler with a set of stock vxWorks headers.

Selecting --target=powerpc-wrs-vxworks and
--with-headers=/gnu/tornado/target/h causes config/rs6000/vxworks.h
to be used, and it contains lines like:

#define CPP_SPEC \
"-DCPU_FAMILY=PPC -D__ppc -D__EABI__  \
  %{t403: -DCPU=PPC403 -D_SOFT_FLOAT ; \
    t405: -DCPU=PPC405 -D_SOFT_FLOAT ; \
    t440: -DCPU=PPC440 -D_SOFT_FLOAT ; \
    t603: -DCPU=PPC603               ; \
    t604: -DCPU=PPC604               ; \
    t860: -DCPU=PPC860 -D_SOFT_FLOAT ; \
        : -DCPU=PPC604}  \
  %{!msoft-float:-D__hardfp}	   \
  %{fpic|fpie: -D__PIC__=1 -D__pic__=1 ; \
    fPIC|fPIE: -D__PIC__=2 -D__pic__=2 } \
  %(cpp_cpu)"

So far so good.

I get to end of the compiler build, then past "Fixing headers", and
onto the build of libgcc.

Here's the problem:

o Fixing headers applies the machine_name_test fix and converts
   occurrences of CPU to __CPU__.

o The specs used by xgcc still say CPU=xyz, so the compile of libgcc
   terminates in confusion as the headers have been rewritten to
   look for __CPU__.

It looks like fixincl has modified to the headers to a form that
is simply unworkable with the specs.

Can anyone enlighten as to what's supposed to happen? Is fixincl
doing the wrong thing, or is the specs file wrong?

Earl

Re: VxWorks specs vs fixincl, machname.h and machine_name_test

[Phil Edwards]

On Fri, Dec 03, 2004 at 04:08:13PM -0800, Earl Chew wrote:
> I'm building a vxWorks PPC cross using gcc 3.4.2 and I'm trying
> to understand how the machname fix is intended to work.

It isn't.  Fixincl should not be run for VxWorks targets.

-- 
Behind everything some further thing is found, forever; thus the tree behind
the bird, stone beneath soil, the sun behind Urth.  Behind our efforts, let
there be found our efforts.
              - Ascian saying, as related by Loyal to the Group of Seventeen

Re: VxWorks specs vs fixincl, machname.h and machine_name_test

[jf]

Hi,
I got the same problem last week using gcc3.4.1 from a Mandrake 
community 10.1
It seems this compiler is buggy
Compiling at home with gcc3.4.3 on debian unstable works !
Updating the Mandrake box solved the problem.

There are still some vxWorks includes to fix but these fix are relly obvious

Regards,

Jean-François


Earl Chew a écrit :

> I'm building a vxWorks PPC cross using gcc 3.4.2 and I'm trying
> to understand how the machname fix is intended to work.
>
> I've provided the compiler with a set of stock vxWorks headers.
>
> Selecting --target=powerpc-wrs-vxworks and
> --with-headers=/gnu/tornado/target/h causes config/rs6000/vxworks.h
> to be used, and it contains lines like:
>
> #define CPP_SPEC \
> "-DCPU_FAMILY=PPC -D__ppc -D__EABI__  \
>  %{t403: -DCPU=PPC403 -D_SOFT_FLOAT ; \
>    t405: -DCPU=PPC405 -D_SOFT_FLOAT ; \
>    t440: -DCPU=PPC440 -D_SOFT_FLOAT ; \
>    t603: -DCPU=PPC603               ; \
>    t604: -DCPU=PPC604               ; \
>    t860: -DCPU=PPC860 -D_SOFT_FLOAT ; \
>        : -DCPU=PPC604}  \
>  %{!msoft-float:-D__hardfp}       \
>  %{fpic|fpie: -D__PIC__=1 -D__pic__=1 ; \
>    fPIC|fPIE: -D__PIC__=2 -D__pic__=2 } \
>  %(cpp_cpu)"
>
> So far so good.
>
> I get to end of the compiler build, then past "Fixing headers", and
> onto the build of libgcc.
>
> Here's the problem:
>
> o Fixing headers applies the machine_name_test fix and converts
>   occurrences of CPU to __CPU__.
>
> o The specs used by xgcc still say CPU=xyz, so the compile of libgcc
>   terminates in confusion as the headers have been rewritten to
>   look for __CPU__.
>
> It looks like fixincl has modified to the headers to a form that
> is simply unworkable with the specs.
>
> Can anyone enlighten as to what's supposed to happen? Is fixincl
> doing the wrong thing, or is the specs file wrong?
>
> Earl
>