why build start files before core gcc pass 2 ?

Yann E. MORIN yann.morin.1998@free.fr
Mon Mar 4 21:14:00 GMT 2013


Thomas, Esben, Wang, All,

On Monday 04 March 2013 Thomas Petazzoni wrote:
[--SNIP--]
> I believe opinions have started to be a bit strong on this matter.

Hmm, not on my side, to be clear.

> I'm
> 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
> bump.

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
configurations working.

> 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:

    gcc-4.7-4.7.2/debian/rules.defs:
    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
    226   endif
    227   ifeq ($(DEB_STAGE),stage2)
    228     with_libgcc := yes
    229     with_shared_libgcc := yes
    230   endif
    231 endif
        [--SNIP--]
    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
provide:
    http://sourceware.org/ml/crossgcc/2013-01/msg00040.html

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):
    http://sourceware.org/ml/crossgcc/2013-02/msg00057.html
    http://sourceware.org/ml/crossgcc/2013-02/msg00060.html

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:
    http://sourceware.org/ml/crossgcc/2013-03/msg00002.html
    http://sourceware.org/ml/crossgcc/2013-03/msg00004.html

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
mails.

Thanks for reading! :-)

Regards,
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 mailing list