Date: Sat, 28 Nov 1998 21:28:50 +1100 (EST) From: John Birrell <jb@cimlogic.com.au> To: winter@jurai.net (Matthew N. Dodd) Cc: freebsd-sparc@FreeBSD.ORG Subject: Re: [Ultra] Compiler, again Message-ID: <199811281028.VAA25135@cimlogic.com.au> In-Reply-To: <Pine.BSF.4.02.9811280330350.17054-100000@sasami.jurai.net> from "Matthew N. Dodd" at "Nov 28, 98 04:37:07 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew N. Dodd wrote: > If that is the case, don't bother calling it 'FreeBSD'. > > Just for kicks I spent a few hours today getting libc from -current to > compile on my NetBSD system. > > I used 'make -m /path/to/nfs/mounted/share/mk' and fabbed up a workable > /usr/include/machine/*.h from looking at NetBSD, and the 2 FreeBSD arch > dirs. > > Now, I've got libc compiling, but not linking shared, which I believe is a > toolchain issue. (actually a crt0.o issue as I have discovered.) > > While I will admit that having a somewhat usable 'bmake' available on the > NetBSD host system makes things easier, getting bmake to compile on other > platforms should be fairly straight-forward (hell, I got it running on > sprite at one point.) > > So, if the toolchain hackers can turn on the sparc and sparc64 stuff in > the source tree I think that getting some of the userland bits going on a > NetBSD/OpenBSD system would be do-able. > > I'm a bit unsure of how to bootstrap on a NetBSD system as 'buildworld' > seems to look at /usr/lib and /usr/include (chroot tree?) (as it turns > out, defining LD_NOSTD_PATH and then LD_LIBRARY_PATH does what I need for > LD) and makes it difficult for me to provide manually compiled libraries > to link the buildworld tools against. If people look at the cvs history for src/Makefile and src/Makefile.alpha, they'll see how the Alpha port was bootstrapped on NetBSD. The first few tools like make, find, etc are compiled using the NetBSD compiler, headers and libraries. As the bootstrapped tools are installed in the obj tree they are executed in preference to the NetBSD tools. When the build gets to libc, it builds that using the NetBSD syscalls so that the linked executables work with the NetBSD kernel. This works for much of the tree. The exceptions are programs which require specific ioctl support (like disklabel, newfs etc). FWIW, I had the start of a m68k port working that way too. The in-tree binutils readily supports the extra architectures. gcc 2.8.X needs to be imported and bmaked in a cross-build friendly way. I know someone who wants mips support done this way. Alpha needs 2.8.X to solve some register allocation issues, and i386 needs better C++. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811281028.VAA25135>