ct-ng: prefix vs install dir for compiling .deb's

Yann E. MORIN yann.morin.1998@anciens.enib.fr
Tue Feb 8 19:50:00 GMT 2011

Matt, All,

On Tuesday 08 February 2011 19:02:06 Matt Sachtler wrote:
> I'm trying to build a toolchain and package it up as a .deb file (or
> any other type of package/archive), the "interesting" part of which is
> that I don't want to have to install the toolchain to its final
> destination when building it.

Hehe! :-) This is not implemented yet.

> Poking around at .config didn't help much- I haven't seen information
> on what CT_INSTALL_DIR does (and admittedly haven't looked through the
> ct-ng source much, but...), however it doesn't seem to play the same
> role as DESTDIR like i'd hoped it would.

Yes, CT_INSTALL_DIR is the variable I was planning to use as DESTDIR.
For now, there is a total confusion in the crosstool-NG code, where
some parts are using CT_PREFIX_DIR, and others are using CT_INSTALL_DIR.

> Is there a way to achieve this cleanly?

Yes, there is a way. But it is not that easy. The most complex part is
about the sysroot. The sysroot must be below the gcc runtime prefix, and
at the same time glibc needs to know where to install its headers and

So we need a way to differentiate between:
- the place where to install things, the 'build-time' sysroot, and
- the place where gcc looks for files at runtime, the 'run-time' sysroot

It should be quite easy, as one can configure gcc with a build-time sysroot
different from the run-time sysroot: the --with-sysroot option tells about
the run-time sysroot, while --with-build-sysroot tells about the sysroot to
use while building gcc.

So we would build the two core gcc-s with a single sysroot, and build the
final gcc with different ones.

*But* it is not as easy at it sounds, because we need to run the final
gcc to build, for example, the gdbserver to run on the target, or the
native gdb to run on the target. And as we did point to a different
sysroot at build-time from the sysroot used at run-time, it means that
the sysroot is not in the place where gcc would expect it to be...

*But*, as we build a fully relocatable toolchain, then one would hope
that gcc believes its being installed out-of-tree to be the same as a
relocation. Hopefully.

So, basically, one would need to configure the final gcc as:

Of course, after doing some janitorial work to cleanup the hell of a
mess of the current situation, due to the existing confusion.

Oh, BTWE, the confusion is all mine, and is because I did not really
plan this out properly, introducing CT_INSTALL_DIR before it was actually

I would work on this myself, but not now (most probably not in this
release cycle at least). So I will gladly accept patches. ;-)

Yann E. MORIN.

|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |

For unsubscribe information see http://sourceware.org/lists.html#faq

More information about the crossgcc mailing list