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]

Not grokking CT-NG directory 'trees'


[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]