Not grokking CT-NG directory 'trees'
Neal Murphy
neal.p.murphy@alum.wpi.edu
Sat Dec 8 05:45:00 GMT 2012
[This may end up being a 'tell the stuffed bear' msg--a trick we used in
college to help freshmen figure out their own problems.]
I'm attempting to use CT-NG in my firewall project's automated build system.
It DLs sources, unpacks CT-NG and builds it. But it doesn't work right. I'm
missing something.
Traditionally, the F/W (Smoothwall) was built for i386 with x86_64 as a 'tech
demo'. I made the build system re-entrant and SMP-aware and modernized most of
the sources. It build just fine on Debian x86 (and with PAE). Alas, the latest
kernels (3.x) don't seem to want to boot in KVM on Debian Squeeze 2.6.32 *with
PAE*. So I've switched to Wheezy x86_64. And cannot get the fool toolchain to
build; I know multi-lib is part of the problem.
At the risk of saying what you already know, the build system builds the
toolchain stage one (binutils, kernel headers, gcc, glibc, and makes
adjustments); then it builds stage 2 with the stage 1 tools (binutils, gcc and
checks for host poisoning). Then it builds the tools and utilities (tcl, wget,
m4, etc.) needed to bootstrap-build the final stage (the F/W product).
Finally, in chroot jail, it preps kernel headers and builds glibc, makes final
adjustments to the toolchain, then builds binutils, gmp, mpfr,zlib, gcc and
the rest of the packages. In stage 1-3, PATH is set to pick up stuff in
/tools/bin before the host so that the built bits are used ASAP. The final
stage is build in a chroot jail so that host progs and libs cannot be used.
Each package built is installed to its own tree and tar'ed up to be used lated
when producing the ISO and/or flash image. In short, it needs a temporary
toolchain until the real host-independent tools are built (ala
LinuxFromScratch).
This process has worked well for years on x86. And still does. But I need to
expand beyond 4GiB RAM and PAE doesn't seem to play nicely with KVM any more.
Thus my move to x86_64.
So I went looking for alternatives and found CT-NG. I've slogged through most
of it and seem to get a toolchain built. But I'm not understanding what is
built, where it is built, where it gets installed, and how to splice it into
my build tree. It's probably in the docs, but I'm just not seeing it.
So. Given
- /a/b/c/d/ctng/crosstool-ng-1.17.0 (where the CT-NG tarball is unpacked,
config'ed and built)
- /a/b/build-root (where final stage packages are installed so they'll be
usable in the jail during the build)
- /a/b/build-root/tools (contains the toolchain and becomes / in jail)
- /tools (a symlink to /a/b/build-root/tools; the root of the tool chain)
- DIR = crosstool-ng-1.17.0
I run (in a makefile)
# PWD is /a/b/c/d/ctng
cd $(DIR); ./bootstrap
# change MAKELEVEL as CTNG's make is down one.
cd $(DIR); sed -i -e 's/\(MAKELEVEL)\),.*0)/\1,1)/' Makefile.in
# Patch the script to check that the install dir itself is writable,
# not its parent
cd $(DIR); sed -i -e 's=$$(dirname \
"$${CT_INSTALL_DIR}")="$${CT_INSTALL_DIR}"=' \
scripts/crosstool-NG.sh.in
cd $(DIR); ./configure $(CONFIG_OPTS)
# build and make CT-NG
cd $(DIR); $(MAKE)
cd $(DIR); $(MAKE) install
# Configure and build the toolchain
# PKG_DIR = /tools; BITS = 64; CTNG_BUILD_DIR = $(DIR)/ctng-build
( \
mkdir -p $(CTNG_BUILD_DIR); \
sed -e 's=DOWNLOADS_DIR=$(DOWNLOADS_DIR)=' \
-e 's=CTNG_BUILD_DIR=.=' \
-e 's=CTNG_DIR=$(PKG_DIR)=' \
< ../crosstool-ng-$(BITS).config > $(CTNG_BUILD_DIR)/.config; \
cd $(CTNG_BUILD_DIR); \
ct-ng oldconfig; \
ct-ng build; \
)
I know where CT-NG itself is built and where it is installed; it works. I know
where the toolchain (binutils, gcc, glibc, etc.) is built. It seems to install
to /tools. This is where I'm missing something that should be obvious; I'll
start conjecturing.
Is it safe to assume that the toolchain CT-NG installed to /tools is complete
of itself and will not reference anything on the host? My build system expects
to use 'gcc', 'ar', 'ld', et alia; can I symlink the progs (like x84_64-swe-
linux-gnu-gcc in /tools/(tuple)/bin to their respective plain names in
/tools/bin?
Adding to my confusion are the apparent similarities between CT-NG's staging,
build and install locations, CT-NG's toolchain staging, build and install
locations, and my own staging, build and install locations. I'm not certain if
the toolchain is really installed where I *think* it is (in /tools).
A final semi-related question. When CT-NG builds for x86_64, does the
resulting toolchain have the ability to build x86_64 multilib binutils, gcc
and glibc? Or will that involve yet another stage of pre-building?
To close, CT-NG clearly builds a usable standalone toolchain and I'm
attempting to shoehorn it into a slightly different structure. I'm close, but
I can't quite reach the cigar yet to smoke it.
Thanks!
--
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc
mailing list