[uClibc] Toolchain procedure questions...

Tue Jul 6 10:44:17 UTC 2004

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