Prev: ports broken by latest commits : audio/tuxguitar and editors/openoffice.org-3-devel
Next: FreeBSD Port: sysutils/eventlog evtlog.h missing facilities
From: Mikhail Teterin on 2 Mar 2010 11:26 Warner Losh wrote: > I'm trying to create a port for gcc and binutils that is configured > for FreeBSD for a given machine. FreeBSD mips, say. binutils was > relatively easy (once I ported our mips support forward). However, > gcc vexes me. This is not an answer to your question, but a related comment... What I always wanted from the various GNU compiler-ports (be they C, Pascal, Fortran, etc.), is for all of the possible architectures to be options: OPTIONS+= MIPS "Enable MIPS arch" on OPTIONS+= FOO "Enable FOO (beta)" off This would be similar to how the ghostscript ports are build -- each printer driver is an option, most of them are ON by default. The options for each GNU-compiler would start from the subset enabled for binutils (a separate port, LIB_DEPENDed on by the ports of compilers and debuggers). The binutilis port would, by default, support ALL architectures known to upstream developers. Eventually, the main system binutils will be built that way too, but it is best to practice on the ports, of course :-) This would allow any FreeBSD machine to generate code for any architecture (being able to /run/ that code has nothing to do with the ability to /generate/ it!), and analyze any core-dump. Ideally, each architecture back-end would be a port of its own -- like Apache "mods", for example -- but, without upstream support, this is way too much hacking... -mi _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org" |