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 _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
