This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See crosstool-NG for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
[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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |