Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Wrong build order for: linux headers + binutils + gcc + glibc

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Ismael Luceno <ismael.luceno AT gmail.com>
  • To: seth AT swoolley.homeip.net
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Wrong build order for: linux headers + binutils + gcc + glibc
  • Date: Sun, 19 Nov 2006 10:27:31 -0300

seth AT swoolley.homeip.net escribió:
> Furthermore, I believe your build order is (perhaps) correct for the
> case where all versions change. Where only one version changes, I don't
> think your order is minimally correct. SMGL strives for minimalistic
> solutions when available.

Well, that's true in some cases, it's not minimal, but a wide view of
the problem.

> Lastly, why is your order below the only way? What if we build binutils
> after gcc (static)? Why build gcc statically? Why is a rebuild of the
> toolchain (in any order) insufficient before a rebuild?

It's not the only way, but a simple one.

A rebuild of the toolchain "in any order" is not acceptable because of
the inter-dependencies between them.

OK, there's the explanation:

1) Linux headers (only if upgrading them)

2) binutils (only if upgrading them):
Built before gcc because gcc depends on some of it's
features to enable some of it's own.

3) gcc (only if upgrading it and glibc):
Only C, without shared libs, without nls, etc.
It should be minimal, because we don't want to waste time on it.

4) glibc (only if upgrading it and gcc)

5) gcc:
Done here because some of it's characteristics depends on glibc.

6) glibc (if upgrading only gcc)

7) binutils:
Only included here to be clear that it should be compiled
again.

> We never tell people that a rebuild will go back and rebuild stuff
> that could get new features from a later built version update. If
> you want that, you can do a rebuild twice and be pretty sure things
> worked (although, you can force a case where this is not the case if
> you wanted to, so technically a rebuild until builds stopped changing
> (which may never happen) is the only real way to be sure).

Why you don't want such nice feature?

Well, maybe not as part of 'rebuild'.

I should be easy, something like:
'sorcery rebuild-toolchain && sorcery rebuild'

Rebuilding two times is very time expensive, I don't think of anybody
wanting that...





Archive powered by MHonArc 2.6.24.

Top of Page