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__mapi__entry_x86-64_tls.h?view=markup >>> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-src__mapi__entry_x86_tls.h?view=markup >>> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-src__mapi__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. -Dimitry
fix-clang-double-symbol-1.diff
Description: Binary data
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
