[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: status update - gcc 4.5 - some what working
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.
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
> 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:
> 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.
Main Index |
Thread Index |