Building a uclibc based toolchain

[Rob Landley]

On 10/20/2011 03:30 AM, stl wrote:
> Hello all,
> I am trying to build my own uClibc based linux toolchain for a new architecture.

I have scripts that do this at http://landley.net/aboriginal which are
just bash scripts you should be able to read along with reasonably easily.

Hint: the "build_section" shell function calls the relevant script out
of sources/sections, all the patches I apply are in sources/patches, and
all the target-secific information is in sources/targets.  The
scriptsthemselves are fully target agnotic and no there aren't even "if
POWERPC" bits in them, I mean got them to actually be _clean_.  90% of
the other plumbing under sources is to make downloading, extracting, and
patching source tarballs, and then deleting the result when done, happen
for you.

The magic I'm doing with the compressed config file format is explained at:

  http://landley.net/aboriginal/FAQ.html#dev_miniconfig

The presentation slides for my big long design talk on this (including
rationale, implementation, and expected use cases) are online in HTML or
PDF format:


http://speakerdeck.com/u/mirell/p/developing-for-non-x86-targets-using-qemu
  http://landley.net/aboriginal/downloads/presentation.pdf

My "why cross compiling sucks" document is at:

  http://landley.net/writing/docs/cross-compiling.html

The syllabus for my cross-compiling tutorial I gave at OLS 2007 is at:

  http://landley.net/ols/ols2007/tutorial.txt

A video of the OLS compiler BOF I hosted in 2008 is at:

http://free-electrons.com/pub/video/2008/ols/ols2008-rob-landley-linux-compiler.ogg

Hopefully something in there is useful to you. :)

> I follow the following steps:
> 
> 1 - I compile binutils
> 2 - I copy the specific and generic linux headers (from my port of
> linux) into ${HEADERS_DIR}
> 3 - I compile gcc only with --enable-language=c and
> --with-headers=${HEADERS_DIR}
> 4 - I compile uClibc with the previously compiled gcc
> 5 - I recompile gcc with --enable-language=c,c++
> 
> All is fine for the four first steps.
> But I have a question:
> 
> When uClibc building is done, where should I install the uClibc
> libraries (libc.a, librt.a, etc...)
> and headers?
> 
> Where gcc expects to find them?

There's a whole rant in the compiler BOF video (which really shouldn't
have been all me talking but people kept asking me questions) about how
the word "pathological" was not invented to describe teh GCC path logic,
 But _should_have been.

The short answer is "it's not that simple".  The long answer wanders
through "kill it with fire" and version-specific workarounds.  Once upon
a time the uClibc guys wrote a wrapper script, which I've updated and
it's what I use in my toolchains:

  http://landley.net/hg/aboriginal/file/1461/sources/toys/ccwrap.c

> Because, when I recompile gcc (step 5), I get GCC_NO_EXECUTABLE fatal error.
> The config.log shows me that the crt1.o and some standard headers are missing..

Here's a blog entry from two years ago where I ranted about compiler
path logic and the six paths the compiler has to keep stright, but which
gcc fundamentally _can't_:

  http://landley.net/notes-2009.html#21-11-2009

There are actually multiple .o files involved here. (If I recall crt1.o
comes from libc, crtbegin.o and crtend.o come from your compiler
implementation), although the six paths breakdown doesn't distinguish
between build-time and runtime dependencies which only really come up
when you're dynamic linking.  (I suppose the dynamic linker path should
be #7 on that list, although the compiler doesn't _use_ it and just has
to record it.  I'm glossing over TLS linking against ld-linux.so because
in that case it's using it _as_ a system library, so that's already
covered.)

Note that ccwrap.c does all thsi by hand, telling teh compiler
"-nostdinc" and "-nostdlib" and then manually explicitly adding back
everything at the correct location.  (Only way to get sane behavior out
of gcc is to take path logic decisions out of its hands.)

Rob