[oe] [RFC] Adding TLS selection choice to metadata

[Khem Raj]

On Tue, Jul 28, 2009 at 11:00 PM, Holger Hans Peter
Freyther<holger+oe at freyther.de> wrote:
> On Wednesday 29 July 2009 09:02:39 Khem Raj wrote:
>> On Tue, Jul 28, 2009 at 9:14 PM, Holger Hans Peter
>>
>> Freyther<holger+oe at freyther.de> wrote:
>> > On Tuesday 28 July 2009 09:22:02 Khem Raj wrote:
>> >> Hi
>> >>
>> >> Enabling TLS support on uclibc/glibc is not sound enough in out build.
>> >> Reason is we depend upon various autotools tests to find out if the
>> >> software combination we chose can support it or not and these tests are
>> >> not doing the correct think many times.
>> >
>> > Have you seen the patch I sent? The title was
>> > [oe] [PATCH] gcc: Pass --enable-tls=no on uclibc builds...
>>
>> I did however nptl/uclibc builds we need TLS support to be enabled
>> and there is no way to differentiate the triplets for a NPTL uclibc
>> toolchain from non NPTL toolchain. In future not all arches will get
>> NPTL support
>> on uclibc at once so we wil have few arches where NPTL will be there and
>> that will require TLS whereas others will use Linux Threads and will
>> have to disable TLS.
>
> To cite my patch:
>
> +# The tls/ntpl support in uclibc is work in progress. For the current
> +# targets we should build gcc with --enable-tls=no. In the future we
> +# might want to enable TLS for certain architectures and uclibc versions
> +# so this is why this method exists.
> +def get_gcc_uclibc_tls_setting(bb, d):
> +    return "--enable-tls=no"
>
>

I was thinking of a case when say nptl is supported on mips
but someone still wants to build with linuxthreads. In your patch you
rely upon the target triplet to decide where to enable it and where
not to. a toolchain with nptl/uclibc or
lt/uclibc has same target triplet. So even for nptl
like uclibc_nptl.bb recipe we will have enable-tls=no
which wont be the correct thing.

> we are basically talking about the same thing? e.g. with the proposed
> TARGET_TLS you would add a if to the above and return "". right?
>
> z.
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>