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]

Re: why build start files before core gcc pass 2 ?


Dear Yann E. MORIN,

On Sat, 2 Mar 2013 16:21:37 +0100, Yann E. MORIN wrote:

> On Saturday 02 March 2013 Esben Haabendal wrote:
> > "Yann E. MORIN" <yann.morin.1998@free.fr> writes:
> > > However, if any one comes up with a way to build NPTL, that does involve
> > > only two gcc steps, and is *sane*,
> > 
> > What is the definition of sane here?
> 
> For one, all current samples continue to work as before.
> 
> Then, a patchset that brings changes one after the other. It might be
> a bit complex to do, since I expect such a change to impact everything
> about all at once, but I'd be very reluctant to apply a thousands-lines
> long patch in the first place.
> 
> Finally, the new code should be commented, and better yet, the whole
> new process should be dully documented and explained.
> 
> > "Prove boyond any doubt" is a really
> > _HARD_ task here, and in this case, for most people not really feasible.
> 
> Yes, this is difficult. But I'm not trading a *known working* situation
> that is not optimum, for a suposedly-better situation that is not working
> (for the sake of not existing so far).
> 
> But, as they used to say: show me the code! ;-)

I believe opinions have started to be a bit strong on this matter. 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.

So really, why don't we ask just the same conditions for this
NPTL-related change than for all other changes? Of course, existing
samples should continue to build, and runtime testing on at least a few
platforms should confirm that things still work.

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.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

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