[Mesa-dev] [LLVMdev] mesa-10.4.4: BROKEN TLS support in GLX with llvm-toolchain v3.6.0rc2
emil.l.velikov at gmail.com
Tue Feb 10 15:09:42 PST 2015
On 10/02/15 13:17, Dimitry Andric wrote:
> On 09 Feb 2015, at 18:52, Sedat Dilek <sedat.dilek at gmail.com> wrote:
>> On Mon, Feb 9, 2015 at 6:44 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>> On 07/02/15 22:42, Sedat Dilek wrote:
>>>> In file included from ../../src/mapi/entry.c:49:
>>>> ./entry_x86-64_tls.h:66:1: warning: tentative array definition assumed
>>>> to have one element
>>>> fatal error: error in backend: symbol 'x86_64_entry_start' is already defined
>>> It may be that it's a bug on our end, but it's a bit painful going
>>> through all the auto generated sources, the 10+ define guards and other
>>> magic that's inside src/mapi. Getting some idea on llvm/clang behaviour
>>> change should help out :-)
>>> Please open a bug-report with llvm and/or mesa, so that we have all the
>>> info in one place and things don't get lost.
>> I am unsure if it is a bug in llvm/clang or in mesa.
>> Shall I open 2 bug-reports - in mesa and llvm BTS?
> Please have a look at this PR, which I opened in May 2014, and which is about the same issue:
>From a quick look at the bug, the llvm/clang devs are quoting the C11
spec, yet we're not building with -std=c11 so I'm not sure that applies.
Feel free to forward that if interested - I'm a bit short on account on
their bugzilla :-)
> The assertion seems to have been transformed now into a backend error, but this may also be because you built clang without assertions. (Did you?)
> In any case, the workaround is to change the static symbols into extern symbols, together with a hidden visibility attribute (as suggested by Rafael Espíndola), similar to the fix I posted in this FreeBSD port bug:
> E.g., you can use these patches:
These patches don't look at all bad. Can you give them a bit of TLS and
send them to the list, please ? This also stands for the other patches
in FreeBSD's repo :-)
More information about the mesa-dev