Am Dienstag, 17. Februar 2015, 10:05:33 schrieb Sedat Dilek: > On Mon, Feb 16, 2015 at 12:45 PM, Marc Dietrich <marvi...@gmx.de> wrote: > > Am Montag, 16. Februar 2015, 12:42:19 schrieb Sedat Dilek: > >> 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-s > >> >> >>> rc_ > >> >> >>> _ma > >> >> >>> pi__entry_x86-64_tls.h?view=markup > >> >> >>> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-s > >> >> >>> rc_ > >> >> >>> _m > >> >> >>> api__entry_x86_tls.h?view=markup > >> >> >>> https://svnweb.freebsd.org/ports/head/graphics/libGL/files/patch-s > >> >> >>> rc_ > >> >> >>> _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 > > > > no that's all, sorry I still have two unrelated patches in my HEAD. So > > this > > should actually have been /2. > > Hehe. > > I haven't had the time to test them. > ( Still doing all my OS updates with UMTS/HSPA. ) > > Can you send a new v2 with only those two patches? > Maybe together with a git-cover-letter? > To all involved people here for easier review.
I'll send a new V3 soon because I forgot a change in V2. Thanks 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
