[uClibc] Toolchain procedure questions...

Tue Jul 6 10:56:34 UTC 2004

I just realized I have been using the words toolchain and buildroot a bit
too loosely when I am, right now, just focusing on toolchain.

I assume the the buildroot package builds a toolchain, then builds native
apps for the chroot environment, whereas the toolchain just builds the dev
tools which have been cross-compiled to build uclibc linked apps. correct?

So buildroot incorporates the functionality of toolchain, plus the
building of the chroot/uml environment (with all the other possible
packages one might want to use).

- Nick

Nick Jennings said:
> Manuel Novoa III said:
>> Hello,
>>
>> On Mon, Jul 05, 2004 at 05:51:36PM +0200, Nick Jennings wrote:
>>> Hi all, I have read several threads from people who have had trouble
>>> getting a grasp on the uClibc toolchain proceedure. The documentation
>>> is non-existent, and what is written about it just points people to
>>> the "auto-magical" build environments which take care of the details
>>> for you.
>>
>> Because there is no documentation to speak of, other than the build
>> process itself as documented in the makefiles of buildroot and
>> toolchain.
>
> That type of documentation is one thing, and although it may take a bit
> longer to decipher when figuring it out for the first time, it's
> commented and can be understood. However, another aspect of
> documentation is explaining what it's all about and what the buildroot
> is for, what the toolchain is for - with examples. Simply saying "to
> build uclibc based applications, you need a toolchain, a toolchain is
> gcc, uclibc, and binutils", is 'correct' but not very explanitory.
> I understand you may not have the time, or patience, to be so verbose
> about something that you know so well that it seems obvious to you.
> Especially when I'm sure there are more pressing matters for you to
> worry about than "hand holding" (for free).
>
>>> I've seen some hostility in regards to people who have made comments
>>> about the lack of documentation, and before I become another target,
>>> I'd like to
>>
>> Hostility?  When?
>
> Ok, maybe just impatience. It wasn't as much as an acusation as an
> attempt to avoid getting the same responses I found in previous
> postings.
>
>
>>> at least attempt to figure this out once and for all and write some
>>> real documentation on the subject. Even if everything is "taken care
>>> of" with the toolchain and/or buildroot tarballs, it does not mean
>>> people do not need to know how to do it by hand.
>>
>> See basic description below.  As far as people needing to know how to
>> do it by hand, either they can follow the build system with perhaps
>> only a couple of questions, or they need extended hand-holding.  We
>> generally don't have the time or resources to support the latter...
>> although I suppose a support contract is an option.
>>
>>> For example. I have no net connection where I am living now. I am
>>> travelling and just have my laptop and a USB key. I go to the
>>> internet cafe's and download all the code and documentation I think
>>> I'm going to need and so therefore the Makefiles which try to
>>> download all the source aren't going to work for me.
>>
>> Not an issue for us, although I believe "make sources" worked at one
>> time.  You have the sources though, so you can fix it if it is
>> currently broken and post patches to the uClibc list if you desire.
>
> After checking it out last night I found 'make source' to download all
> the sources prior to the build process. Which is useful enough. Also,
> in my case, if I put the source tarballs in the sources/dl/ directory,
> the make scripts will use them. Although I have to modify the make/*.mk
> files to reflict my versions of the packages, which ended up causing
> problems with the patches.
>
>
>>> The other reason the pre-build environments, or automated build
>>> scripts aren't going to work for me is I want to understand fully
>>> what's going on- it's more of a research project than a pragmatic
>>> "this needs to get done" project. I'm pretty fuzzy when it comes to
>>> the details of this process and would like to become a bit more
>>> fluent in my understanding.
>>
>> Basicly...
>>
>> 1) unpack uClibc and the kernel headers
>
> I built my own kernel, and used those headers (easy enough)
>
>
>> 2) configure uClibc
>> 3) unpack binutils
>> 4) apply binutils patches to add support for <arch>-linux-uclibc
>> tuples
>
> Aha! here is the first problem (and as far as I got last night, using
> your email as a reference).
> The patch files were generated based on binutils-2.14.90.0.7 ... what's
> the difference between this and just 2.14? I don't know, but based on
> the timestamp on the ftp.kernel.org site, it's from Oct. 2003. The
> patches generate lots of .rej files when I try to patch against just
> plain 2.14 or 2.15 (this was the first patch, x-001-debian.patch).
> Why is it necessary to maintain these patches yourselves? Isn't that a
> bit of a PITA? Any new version comes out, and a new patch must be
> created. Can't they be submitted to the maintainers for incorporation?
> or are they hacks?
>
>
>> 5) configure and build cross binutils
>> 6) unpack gcc
>> 7) apply gcc patches to add support for <arch>-linux-uclibc tuples,
>>   including the necessary patches for libstdc++ to teach it about
>>   uClibc ctype and locale internals
>> 8) configure and build gcc-initial
>> 9) build uClibc using gcc-initial
>> 10) configure and build gcc-final... the cross gcc targeted for uClibc
>> 11) configure and build native uClibc versions of binutils and gcc for
>>    the target (if desired... buildroot only)
>>
>> For specifics, see the makefiles and patches.  You can also ask... but
>> the answer might simply be "because that's what got it working".
>>
>
> Thank you very much for the steps though, they are very helpful in
> understanding the process better and have also helped me to decipher
> the makefile process a bit more. I'll have more questions as I get to
> the later steps I think.
>
> I've still got a ways to go to get this whole process working and
> documented, but I'm hoping it will be of use to others once I'm done. I
> could easily just say "use buildroot" and maybe explain a little bit of
> how to so (i.e. make, or make source... etc.), but what I am shooting
> for is more of an explination of what buildroot is doing.
>
> Thanks for your help.
> - Nick
>
>
>
>
>
>
> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://uclibc.org/mailman/listinfo/uclibc