Re: status update - gcc 4.5 - some what working

[Adam Ciarciński <adam%viamedium.pl@localhost>]

Building the system on Mac OS X gives me:

In file included from /dist/src/external/gpl3/gcc/dist/gcc/vec.c:29:
/dist/src/external/gpl3/gcc/dist/gcc/system.h:402:20: error: malloc.h: No such 
file or directory

When I manually comment '#include <malloc.h>' out in the 
external/gpl3/gcc/dist/gcc/system.h, the build continues, but I am not sure 
this is a proper solution.

Kind regards,
Adam


On 2011-07-05, at 00:39, matthew green wrote:

> 
> hi folks.
> 
> 
> if you've been following source-changes, you'll have noticed a lot of
> traffic related to gcc 4.5 update.  at this point, many platforms are
> very ready for testing.  these platforms are known to work mostly
> completely:
> 
>       amd64
>       i386
>       powerpc
>       arm
>       sparc
>       sparc64 [*]
> 
> [*] have to compile crt0.o with -O1 or it faults all binaries when
> they are trying to start up.  possible codegen issue, but until i've
> looked closer i'm not yet going to blame gcc :-)
> 
> 
> everything else, besides the non-functional ia64 and powerpc64 ports,
> at least gets as far as trying to build code before failing.
> 
> - m68* is the worst off -- both m68k and m68000 crash building libgcc.
> - mips platforms have a new error that exists with gcc 4.1 as well
>  related to rump, but otherwise seem to build ok.
> - vax needs a lot of hacks, most commited except for the most ugly.
> - armeb probebly works, it builds.
> - sh3 needs some new functions implemented in libkern (__udivsi3_i4i
>  and __sdivsi3_i4i) and has some other issues for sh3el.
> 
> i've done some minor testing with pkgsrc on i386 and amd64 and have
> had much more success than i expected.  the only failures related
> to gcc itself were eg, pkgs using bsd.prog.mk ie, -Werror and new
> warnings triggering build failures.  however, qt4 and kde4 both
> were able to be built without any help, for instance.
> 
> 
> the way to test these is to set "HAVE_GCC=45" in your environment,
> and apply at least the sys/mbuf.h and sys/cdefs.h changes from the
> following patch into your tree:
> 
>       http://www.netbsd.org/~mrg/gcc-4.5-diffs.20110704-1534.diff
> 
> we are still working on real solutions to the above changes, but
> they are essential to building userland and kernels.  the other two
> changes are only for vax and m68k.
> 
> you should be able to do this for all buildable ports and have it
> fail at some usefully fixable point, though not always.  if you want
> to try, please contact me (or tech-toolchain) for any more help.
> 
> 
> .mrg.