On Mon, Feb 16, 2015 at 10:39 AM, Marc Dietrich <marvi...@gmx.de> wrote: > 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. >
Sorry for the late response... troubles with my Internet connection. Those two patches or do I need more? [PATCH 1/4] configure: add visibility macro detection to configure [PATCH 2/4] add visibility hidden to tls entry points Regards, - Sedat - [1] http://lists.freedesktop.org/archives/mesa-dev/2015-February/076980.html [2] http://lists.freedesktop.org/archives/mesa-dev/2015-February/076979.html _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
