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
>