This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See crosstool-NG for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |