Am Samstag, 14. Februar 2015, 18:20:12 schrieb Dimitry Andric: > On 11 Feb 2015, at 11:16, Sedat Dilek <sedat.di...@gmail.com> wrote: > > On Wed, Feb 11, 2015 at 12:09 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > >> On 10/02/15 13:17, Dimitry Andric wrote: > >>> On 09 Feb 2015, at 18:52, Sedat Dilek <sedat.di...@gmail.com> wrote: > >>>> On Mon, Feb 9, 2015 at 6:44 PM, Emil Velikov <emil.l.veli...@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 > >>>>>> x86_64_entry_start[]; > >>>>>> ^ > >>>>>> 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: > >>> http://llvm.org/PR19778 > >> > >> Hi Dimitry, > >> > >> 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: > >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192286 > >>> > >>> E.g., you can use these patches: > >>> > >>> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-src__ma > >>> pi__entry_x86-64_tls.h?view=markup > >>> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-src__m > >>> api__entry_x86_tls.h?view=markup > >>> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-src__m > >>> api__entry_x86_tsd.h?view=markup>> > >> 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 :-) > > > > On the one hand I am glad to see that there are patches available. > > I will give them a try when I am at home. > > On the other hand - knowing FreeBSD switched to llvm/clang as > > default-compiler - it's abit pity to see that stuff like this is not > > shared with upstream (did not look at the date of submission). > > If you have more patches in this area, please share them with upstream. > > The complete collection is here: > > https://svnweb.freebsd.org/ports/head/graphics/libGL/files/ > > I didn't create most of these patches, so I can't really say what the > reason for them was, or whether they still apply to Mesa master. > > In any case, for this specific issue with Mesa's TLS related definitions > breaking clang, please consider the attached patch.
I think there is no need to restrict this to clang only as it also works with gcc. I submitted a slightly different version to the mesa list which uses a macro instead and also adds some credits. Marc
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
