From owner-freebsd-sparc Sun Mar 31 14:50:10 2002 Delivered-To: freebsd-sparc@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id E9B4F37B400; Sun, 31 Mar 2002 14:49:53 -0800 (PST) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by kayak.xcllnt.net (8.11.6/8.11.4) with ESMTP id g2VMnrb21966; Sun, 31 Mar 2002 14:49:53 -0800 (PST) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.2/8.12.2) with ESMTP id g2VMnrEF015584; Sun, 31 Mar 2002 14:49:53 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.2/8.12.2/Submit) id g2VMnr3Q015583; Sun, 31 Mar 2002 14:49:53 -0800 (PST) Date: Sun, 31 Mar 2002 14:49:52 -0800 From: Marcel Moolenaar To: ia64@FreeBSD.org, sparc@FreeBSD.org Cc: ru@FreeBSD.org Subject: Buildworld with an external cross-compiler (long!) [PATCH] Message-ID: <20020331224952.GA8128@athlon.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [Ruslan: please consider this a re-request for review. Feel free to commit anything you think is correct (or ask me to do it), and give your comments and/or suggestions for the things you don't think are correct and/or want to see done differently] Gang, A patch to support building world for an architecture for which we don't have the compiler support in the source tree yet, can be found here: http://www.xcllnt.net/~marcel/xxtools.diff I did not try to make the patch such that we can build everything yet. That's something we can add later if desired (a reason for this would be to support a buildworld with a non-GNU compiler for various reasons such as correctness and/or performance). Anyway, what follows is a description of what the patch does and one way you can use it. The most important variable is the XX_TOOLS variable. When this variable is defined, certain behaviour is suppressed, such as: o building a cross-compiler with which world is built, o building the compiler as part of the world phase, o not building certain toolchain sensitive libraries and tools. When XX_TOOLS is set (it doesn't matter what value it has), the user is responsible to set the following variables as well: XX_AR, XX_AS, XX_CC, XX_CPP, XX_CXX, XX_LD, XX_NM, XX_OBJCOPY, XX_OBJDUMP, XX_RANDLIB, XX_SIZE The meaning of these variables should be clear. Furthermore, the patch depends on an enhancement in install(1) that has been discussed on -arch before. The enhancement is to have install(1) use a different strip(1) than "strip". This is part of the patch. The environment variable for this is STRIPBIN, since STRIP is already taken. The last environment variable, XX_RUNTIME, can be used to tell the build to link usr/include and usr/lib in the temporary world tree (ie /usr/obj/ia64/usr/src/i386 when crossbuilding ia64 on i386) to existing directories under the XX_RUNTIME tree. The effect is that when the temporary world tree is populated, the headers and libs will be written into XX_RUNTIME. A typical use is given in the sample wrapper script that follows: \begin{xmake.sh} #!/bin/sh export XX_TOOLS="/usr/local/bin/ia64-unknown-freebsd5.0" export XX_AR="${XX_TOOLS}-ar" export XX_AS="${XX_TOOLS}-as" export XX_CC="${XX_TOOLS}-gcc" export XX_CPP="${XX_TOOLS}-cpp" export XX_CXX="${XX_TOOLS}-g++" export XX_LD="${XX_TOOLS}-ld" export XX_NM="${XX_TOOLS}-nm" export XX_OBJCOPY="${XX_TOOLS}-objcopy" export XX_OBJDUMP="${XX_TOOLS}-objdump" export XX_RANLIB="${XX_TOOLS}-ranlib" export XX_SIZE="${XX_TOOLS}-size" export XX_RUNTIME=/usr/local/ia64-unknown-freebsd5.0 export STRIPBIN=${XX_TOOLS}-strip make -DNO_CXX -DNO_OBJC -DNO_WARNS TARGET_ARCH=ia64 $@ \end{xmake.sh} By setting XX_RUNTIME to /usr/local/, you automaticly cause the headers and libraries to be updated/installed in the place where the compiler will look for them, without any hackery. If you can achieve the same with options (like -isystem), you can keep XX_RUNTIME undefined and/or point it to a completely different location (like NFS mounted root filesystem of the machine you're building for). To make the above wrapper script work in it's presented form, you need to do some one-time setup first: you need to make sure that XX_RUNTIME has a valid layout: o create directories ${XX_RUNTIME}/usr/include and ${XX_RUNTIME}/usr/lib. o link ${XX_RUNTIME}/include to ${XX_RUNTIME}/usr/include (only needed for GNU compiler). o link ${XX_RUNTIME}/lib to ${XX_RUNTIME}/usr/lib after moving ldscripts to usr/include (only for GNU compiler). o make sure ${XX_RUNTIME}, ${XX_RUNTIME}/usr/include and ${XX_RUNTIME}/usr/lib are writable by whomever you do buildworlds with. o In the case of GNU, make sure that you don't have conflicting includes under /usr/local/lib/gcc-lib/... The includes there are created by fixincludes or something and are found before the ones in ${XX_RUNTIME}/usr/include. With the above, doing a buildworld is as easy as: xmake.sh buildworld Installation is as easy as: xmake.sh installworld DESTDIR= I think it should be sufficiently clear for everybody to try this themselves. Let me quickly go over the changes in the patch: o Most of the conditional assignments based on XX_TOOLS are to avoid doing things that we don't expect to work anyway. This mostly includes toolchain sensitive programs, libraries. In Makefile.inc1 we actually annotate CROSSENV based on it so that we cause the right compiler to be picked up, o We exclude sysinstall(8) for anything but alpha and i386, o The changes in contrib/amd resolve compilation failures, o Make gperf(1) and groff(1) conditional on NO_CXX. We cannot build those if we don't build libstdc++, o Of course we have perl(1) changes: the perl makefiles that are generated, redefine CC and friends. This works in a "normal" buildworld, because we pick up the right compiler by way of setting PATH. In this case, it's fatal. Hence, we explicitly set CC on the (sub-) make commandline. There's 1 case where this fails to work and that is SDBM_File. The reason for this is that SDBM_File has an additional level of recursion (ie a subdir) and we recurse into that directory from a generated makefile in which we cannot set CC and friends explicitly. Hence CC gets destroyed. o Exclude xlint(1) because it fails to build and the problem didn't look trivial enough to spend much time on it, o Allow install(1) to use a different "strip". Note that xinstall is already in the bootstrap-tools, so this will magically work. A final word (finally :-) I completed a successful buildworld last night, but have a build failure when applying the patches on a virgin machine. I also didn't try a "normal" buildworld with these patches applied. My main objective is to update my ia64 box and share this patch early enough that people can try it out themselves and give feedback. FYI, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message