llvm dev - Feb 2015 - [LLVMdev] [Mesa-dev] mesa-10.4.4: BROKEN TLS support in GLXwith 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>

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.

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>

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

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>

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>