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] |
"Yann E. MORIN" <yann.morin.1998@free.fr> writes: > Wang, All, > > First, asking the same question over-and-over again, on the list or by > private mail, will not make for a faster answer. > > Please, be patient. If nobody answers, maybe nobody really knows. > > On Thursday 17 January 2013 Wang Baisheng wrote: >> In build script gcc.sh, I found a comments: >> >> "In case the threading model is NPTL, we need a shared-capable core gcc". >> >> Yes, shared-capable gcc will need crt*.o, because libgcc*.so will >> linked with crt*.o. Accoring build script, in fact, the option >> "--disable-shared" is removed when building core gcc pass 2. >> >> So if the anwser is : To support NPTL, we need a cross gcc with >> "--enable-shared", i.e., building libgcc_.so instead of libgcc.a. >> while linking libgcc_s.so, link editor need crt*.o, so build crt*.o >> before building core gcc pass 2 ? >> >> If above is true, the question is transfered to : why need a >> shared-capable core gcc to build NPTL ? > > This is a very complex question, for which I do not have the absolute > answer. > > There are two ways to approach this problem: the academic point of view, > and the pragmatic point of view. > > First, the pragmatic view point: everybody does it this way: crosstool-NG > openembedded, buildroot, all major distros... So it is a known way of > having an NPTL toolchain, with no need to have to solve new issues no one > will really be interested to investigate, as a working solution already > exists. > > That's probably not a satisfiable answer for some, but as it does get the > job done, most of us are just happy with that. > > Now, from the academic stand point. NPTL is partly implemented by the > kernel, by the C library, and by the compiler. How these play together > is a bit obscur to me. So if everybody else does something slightly wrong, we will do the same ;-) FWIW, long ago I refactored the OpenEmbedded gcc and glibc recipes to get rid of this additional step when doing NPTL. And it worked fine. Unfortunately, the work was never merged. As I remember it, based on the same arguments of people not really understanding. I think it would be interesting if we could try to see if ct-NG could get this done right. It should save other people from spending time trying to figure out why this is so :-) /Esben -- 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] |