Dimitry Andric
2015-Feb-14 17:20 UTC
[LLVMdev] mesa-10.4.4: BROKEN TLS support in GLX with llvm-toolchain v3.6.0rc2
On 11 Feb 2015, at 11:16, Sedat Dilek <sedat.dilek at gmail.com> wrote:> > On Wed, Feb 11, 2015 at 12:09 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote: >> 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 >>>>>> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-clang-double-symbol-1.diff Type: application/octet-stream Size: 1775 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150214/05b1aece/attachment.obj> -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150214/05b1aece/attachment.sig>
Marc Dietrich
2015-Feb-16 09:39 UTC
[LLVMdev] [Mesa-dev] mesa-10.4.4: BROKEN TLS support in GLXwith llvm-toolchain v3.6.0rc2
Am Samstag, 14. Februar 2015, 18:20:12 schrieb Dimitry Andric:> On 11 Feb 2015, at 11:16, Sedat Dilek <sedat.dilek at gmail.com> wrote: > > On Wed, Feb 11, 2015 at 12:09 AM, Emil Velikov <emil.l.velikov at gmail.com>wrote:> >> 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 > >>>>>> 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 isabout 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 externsymbols, 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150216/de17f5cd/attachment.sig>
Sedat Dilek
2015-Feb-16 11:42 UTC
[LLVMdev] [Mesa-dev] mesa-10.4.4: BROKEN TLS support in GLXwith llvm-toolchain v3.6.0rc2
On Mon, Feb 16, 2015 at 10:39 AM, Marc Dietrich <marvin24 at gmx.de> wrote:> Am Samstag, 14. Februar 2015, 18:20:12 schrieb Dimitry Andric: >> On 11 Feb 2015, at 11:16, Sedat Dilek <sedat.dilek at gmail.com> wrote: >> > On Wed, Feb 11, 2015 at 12:09 AM, Emil Velikov <emil.l.velikov at gmail.com> > wrote: >> >> 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 >> >>>>>> 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
Sedat Dilek
2015-Feb-17 11:36 UTC
[LLVMdev] mesa-10.4.4: BROKEN TLS support in GLX with llvm-toolchain v3.6.0rc2
On Sat, Feb 14, 2015 at 6:20 PM, Dimitry Andric <dimitry at andric.com> wrote:> On 11 Feb 2015, at 11:16, Sedat Dilek <sedat.dilek at gmail.com> wrote: >> >> On Wed, Feb 11, 2015 at 12:09 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote: >>> 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 >>>>>>> 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. >Applying an adapted version to fit mesa v10.4.4 causes the following errors: ... make[4]: Entering directory `/home/wearefam/src/mesa/mesa-git/src/mapi' CCLD shared-glapi/libglapi.la clang version 3.6.0 (tags/RELEASE_360/rc2) Target: x86_64-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.2 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 "/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -shared -o shared-glapi/.libs/libglapi.so.0.0.0 /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.9/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/4.9 -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../.. -L/opt/llvm-toolchain-3.6.0rc2/bin/../lib -L/lib -L/usr/lib .libs/shared_glapi_libglapi_la-entry.o .libs/shared_glapi_libglapi_la-mapi_glapi.o .libs/shared_glapi_libglapi_la-stub.o .libs/shared_glapi_libglapi_la-table.o .libs/shared_glapi_libglapi_la-u_current.o .libs/shared_glapi_libglapi_la-u_execmem.o -lpthread /usr/lib/x86_64-linux-gnu/libexpat.so --gc-sections --no-undefined -soname libglapi.so.0 -lgcc --as-needed -lgcc_s --no-as-needed -lpthread -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.9/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o /usr/bin/ld: .libs/shared_glapi_libglapi_la-entry.o: relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC .libs/shared_glapi_libglapi_la-entry.o: could not read symbols: Bad value clang: error: linker command failed with exit code 1 (use -v to see invocation) make[4]: *** [shared-glapi/libglapi.la] Error 1 make[4]: Leaving directory `/home/wearefam/src/mesa/mesa-git/src/mapi' Can you look at this (see also attached tarball)? - Sedat - -------------- next part -------------- A non-text attachment was scrubbed... Name: for-andric.tar.gz Type: application/x-gzip Size: 11061 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150217/73d1af66/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: for-andric.tar.gz.sha256sum Type: application/octet-stream Size: 84 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150217/73d1af66/attachment.obj>
Sedat Dilek
2015-Feb-17 11:55 UTC
[LLVMdev] mesa-10.4.4: BROKEN TLS support in GLX with llvm-toolchain v3.6.0rc2
On Tue, Feb 17, 2015 at 12:36 PM, Sedat Dilek <sedat.dilek at gmail.com> wrote:> On Sat, Feb 14, 2015 at 6:20 PM, Dimitry Andric <dimitry at andric.com> wrote: >> On 11 Feb 2015, at 11:16, Sedat Dilek <sedat.dilek at gmail.com> wrote: >>> >>> On Wed, Feb 11, 2015 at 12:09 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote: >>>> 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 >>>>>>>> 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. >> > > Applying an adapted version to fit mesa v10.4.4 causes the following errors: > > ... > make[4]: Entering directory `/home/wearefam/src/mesa/mesa-git/src/mapi' > CCLD shared-glapi/libglapi.la > clang version 3.6.0 (tags/RELEASE_360/rc2) > Target: x86_64-unknown-linux-gnu > Thread model: posix > Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 > Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 > Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 > Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.2 > Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 > Candidate multilib: .;@m64 > Candidate multilib: 32;@m32 > Selected multilib: .;@m64 > "/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m > elf_x86_64 -shared -o shared-glapi/.libs/libglapi.so.0.0.0 > /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o > /usr/lib/gcc/x86_64-linux-gnu/4.9/crtbeginS.o > -L/usr/lib/gcc/x86_64-linux-gnu/4.9 > -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu > -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu > -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../.. > -L/opt/llvm-toolchain-3.6.0rc2/bin/../lib -L/lib -L/usr/lib > .libs/shared_glapi_libglapi_la-entry.o > .libs/shared_glapi_libglapi_la-mapi_glapi.o > .libs/shared_glapi_libglapi_la-stub.o > .libs/shared_glapi_libglapi_la-table.o > .libs/shared_glapi_libglapi_la-u_current.o > .libs/shared_glapi_libglapi_la-u_execmem.o -lpthread > /usr/lib/x86_64-linux-gnu/libexpat.so --gc-sections --no-undefined > -soname libglapi.so.0 -lgcc --as-needed -lgcc_s --no-as-needed > -lpthread -lc -lgcc --as-needed -lgcc_s --no-as-needed > /usr/lib/gcc/x86_64-linux-gnu/4.9/crtendS.o > /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o > /usr/bin/ld: .libs/shared_glapi_libglapi_la-entry.o: relocation > R_X86_64_32S against `.rodata' can not be used when making a shared > object; recompile with -fPIC > .libs/shared_glapi_libglapi_la-entry.o: could not read symbols: Bad value > clang: error: linker command failed with exit code 1 (use -v to see invocation) > make[4]: *** [shared-glapi/libglapi.la] Error 1 > make[4]: Leaving directory `/home/wearefam/src/mesa/mesa-git/src/mapi' > > Can you look at this (see also attached tarball)? >Adding "-fPIC" to my {C,CXX}FLAGS seems to fix this.>From my v2 build-script:... export CC="clang -v" export CFLAGS="-Qunused-arguments -fPIC" export CXX="clang++" export CXXFLAGS="$CFLAGS" export CPP="clang-cpp" export CPPFLAGS="-I$PREFIX/include" ... - Sedat - -------------- next part -------------- A non-text attachment was scrubbed... Name: build_mesa-with-llvm-v2.sh Type: application/x-sh Size: 4110 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150217/875c92ae/attachment.sh> -------------- next part -------------- A non-text attachment was scrubbed... Name: build-and-install-log_mesa-10-4-4_llvm-3-6-0-rc2_gallivm-fixes_clang-fixes-freebsd_enable-glx-tls_fPIC.txt.gz Type: application/x-gzip Size: 85255 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150217/875c92ae/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: build-and-install-log_mesa-10-4-4_llvm-3-6-0-rc2_gallivm-fixes_clang-fixes-freebsd_enable-glx-tls_fPIC.txt.gz.sha256sum Type: application/octet-stream Size: 176 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150217/875c92ae/attachment.obj>
Possibly Parallel Threads
- [LLVMdev] [Mesa-dev] mesa-10.4.4: BROKEN TLS support in GLXwithllvm-toolchain v3.6.0rc2
- [LLVMdev] mesa-10.4.4: BROKEN TLS support in GLX with llvm-toolchain v3.6.0rc2
- [LLVMdev] mesa-10.4.4: BROKEN TLS support in GLX with llvm-toolchain v3.6.0rc2
- [LLVMdev] mesa-10.4.4: BROKEN TLS support in GLX with llvm-toolchain v3.6.0rc2
- [LLVMdev] mesa-10.4.4: BROKEN TLS support in GLX with llvm-toolchain v3.6.0rc2