FreeBSD Port: mplayer-0.99.11_14
tinguely at casselton.net
Mon Jul 27 16:05:46 UTC 2009
As a FYI and cross my fingers that this does not take an OT life of its own.
The newer ARM chips could benefit from a new GCC and GNU binutils. So
we have spent some time experimenting in this area.
I have added the FreeBSD kernel printing extensions (-fformat-extensions)
and the FreeBSD path (PREFIX) code and the freebsd config entries into the
GCC 4.5 (have kept it updated to the July snapshot). The GCC and libgcc have
been ported to BSD Makefiles, with the following exceptions:
1) I have not added the last two week changes to gcc/gcclibs.
2) for some reason gnu/usr.bin/cc/cc_tools/option.h must exist,
even if blank, before the compile begins. It must be a makefile
3) In libdecnumber from GCC, I statically chose the dpd routines.
4) libgcc compiles with 8.0 header files. I believe there are errors
in the gcc libssp. If I remember, it was an error with an include file
that I got manually around.
5) libgmp/libmpfr required by the new compilers has not been ported,
right now I link them against /usr/local/lib. libgmp looks the
messiest of the two. In the mpn directory, there are generic routines
and per ARCH and sub-ARCH assembly replacements which require m4
preprocessing. Some replacements are for both add and subtract versions:
aors_n.asm is equivalent to add_n.asm and sub_n.asm.
For the ARM, I changed the hardware floating point to be "vfp".
I see there are ARCH restrictions of "NOT_FOR_ARCHS= alpha ia64 powerpc"
in the newer GCCs.
I have used the ported compiler mostly on the kernel sources. The standard
GCC 4.5 "-O" option kicks up several new warnings on the inline that
are conditional - a lot of them are inlines for locks.
I use the new binutils, but have not tried to port them to the BSD makefiles.
This is just a FYI of some of what would be require to update the native
compiler. I hate to think what port source issues would be.
More information about the freebsd-multimedia