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 ?


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