Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 31 Mar 2002 14:49:52 -0800
From:      Marcel Moolenaar <marcel@xcllnt.net>
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>

next in thread | raw e-mail | index | archive | help
[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/<compiler>, 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=<whereever>

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-ia64" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020331224952.GA8128>