Subject: Re: Toolchain status list
To: Todd Vierling <email@example.com>
From: James Chacon <firstname.lastname@example.org>
Date: 10/05/2001 12:54:21
>: > - Create tools build procedure for other tools needed on non-NetBSD hosts
>: > (and verify buildability on Cygwin, Solaris/x86, and Linux)
>: I've got crunchgen, crunchide, msgc and menuc done and will check that support
>: in shortly.
>Do *not* check in a non-bfd crunchide into src/tools. That is not a
>cross-platform capable tool. 8-)
Actually what I'll do is #define some temp changes into crunchgen to replace
crunchide with objcopy and have the tools/crunchgen turn that on for now until
all platforms are done.
(the current objcopy is pretty braindead and can't support this at all
regardless of the docs claiming otherwise. objcopy -S -k <sym> works just
fine with the new binutils though)
>(If you wouldn't mind, could you please send me a tarball of your files that
>you have added to src/tools before committing?)
>: Groff is the only other nasty one beyond locale issues that I saw.
>Yah. "cross-groff" is going to be built from GNU build processes just like
>toolchain and texinfo.
I figured as much when I did an initial look last night (then my head hurt :)
>: To support non-native builds a primer probably also needs to be written
>: which lists dependencies (you need a C and C++ compiler, make, and posix
>: compatible userland, etc).
>Actually, you should only need a C compiler, make, and POSIXish system, but
>some tools will need compatibility hacked into them to make this happen
>(this is a high priority task directly from my employer). I'll add an item
>for "document cross build environment requirements".
You need groff to cross compile a make build/release. Groff requires a C++
compiler unless you plan on building 2 gcc's - 1 for native and 1 for cross
>: > - Create somewhat better strategy for "cleandir" in tools
>: It's not real obvious on how some of that works when I'd cleandir in a tool
>: and it would refuse to rebuild.
>These points aren't related; my bulleted item has to do with investigating
>whether descending from top level into "tools" on cleandir was a good idea.
>The tools build has a very special method of rebuilding -- it allows tools
>to be cleandir'd, but still not rebuilt unless the tool was actually
>updated. There's special timestamp checks involved, as well as a
>three-state MKTOOLS (no/yes/always). If you always want the tools rebuilt,
>you can set MKTOOLS=always.
I saw all that (and the timestamp stuff). Just wasn't clicking as the most
obvious at times either. I really think if all the object files are gone it
should also rebuild itself.