tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

status update - gcc 4.5 - some what working

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 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.


Home | Main Index | Thread Index | Old Index