why build start files before core gcc pass 2 ?
Yann E. MORIN
Mon Mar 4 21:14:00 GMT 2013
Thomas, Esben, Wang, All,
On Monday 04 March 2013 Thomas Petazzoni wrote:
> I believe opinions have started to be a bit strong on this matter.
Hmm, not on my side, to be clear.
> not sure to understand why you would like this particular change to
> provide more proofs that it is absolutely correct than all other
> changes that go in Crosstool-NG? For example, the default gcc/binutils
> version are regularly bumped, even though nobody has ever provided a
> firm and definitive proof that nothing gets broken by the gcc/binutils
This is, IMHO, very different than adding a new gcc/binutils/whatever
version. Adding a new version does not remove the existing ones, so it
is still possible to build previously existing configurations.
This, OTOH, would rip existing code/steps, and replace it with alternate
code/steps, so it is not so trivial in the first place to keep existing
> So really, why don't we ask just the same conditions for this
> NPTL-related change than for all other changes?
I am uneasy at changing this, since it really touches the core of the
code. It was quite complex to come up with, and, as this very thread
proves, not well understood.
What I meant is that we now have a working solution, that is mostly agreed
on by different projects. By Esben's own words, this is how OE does it (or
at least, used to do it until very recently). AFAICS, this is also how
Debian does it (even in Wheezy), as this seems to imply:
219 ifdef DEB_STAGE
220 with_cdev := yes
221 separate_lang := yes
222 # "stage1" is minimal compiler with static libgcc
223 # "stage2" is minimal compiler with shared libgcc
224 ifeq ($(DEB_STAGE),stage1)
225 with_shared_libgcc := no
227 ifeq ($(DEB_STAGE),stage2)
228 with_libgcc := yes
229 with_shared_libgcc := yes
404 ifndef DEB_STAGE
[--SNIP final gcc--]
890 endif # ifndef DEB_STAGE
Which means they have three code-paths:
- one for which DEB_STAGE is set to 'stage1'
- one for which DEB_STAGE is set to 'stage2'
- one for which DEB_STAGE is unset
BTW, this is also the way Buildroot does it ;-) and it was added much
later, by people that have a track-record on working on gcc/glibc/uClibc
(ie. Khem Raj, in commit cfbf8abc33d86a0cf5c1bb3e0817a22009b7f301).
> Of course, existing
> samples should continue to build, and runtime testing on at least a few
> platforms should confirm that things still work.
Yes, that's my main concern.
> The way you've put things in this thread really doesn't encourage
> people to contribute, which I think is quite sad. Especially when the
> proposed change has the potential of simplifying the build process,
> reducing the amount of code, and the overall build time.
I'm sorry if anyone took this as an incentive not to contribute. That was
not my intention. Of course I welcome contributions! Even contributions
that touch deeply in the code.
But in this case, I prefer to stand on the conservative side, and wait for
actual code, and very detailed explanations on how that new code works.
Maybe my wording was too strict, and in retrospect, "proven beyond any
doubt" was probably too strong.
Re-reading my mails, I can't see how I was being heated. In my first reply
to Wang, I just explained the state of the affairs: known-working solution
as a pragmatic approach vs. an academic explanation I was not able to
Then, more than a month passes, and Esben suggested we look at migrating
crosstool-NG to use a two-pass sequence. To which I replied I did not
completely understand the NPTL requirements, and I would need to be
convinced with hard proof (and code):
Esben then questioned what I meant by a "hard proof", to which I replied
that the change be documented and the code commented, and that existing
samples should still build. I fail to see how this could be interpreted
as a refusal of any contribution, and even suggested to submit some code:
Now, let me make it clear:
- I do not completely understand why we need a three-pass sequence,
- the current NPTL sequence was hard to come with, and is working,
- I accept it is not necessarily the optimum or best solution, and that
it might not even be a correct solution, and I accept the current state
as a pragmatic approach, which is better than nothing,
- I will gladly review and test a patch(set) that implements a better
solution; better, as in: [explained-and-documented [correct [faster]].
And a final word: my apologies to anyone who felt offended by my previous
Thanks for reading! :-)
Yann E. MORIN.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc