Various issues with Clang and libc++ while playing with OpenCL (FYI)

[Dimitry Andric]

On 05 Mar 2014, at 12:30, Jean-Sébastien Pédron <dumbbell at FreeBSD.org> wrote:
> I'm trying to make OpenCL work on FreeBSD, using Mesa 10.1 release
> candidate.

Very nice to hear!


> The implementation of libOpenCL.so in Mesa, called Clover, is in C++. In
> the configure.ac script, they require GCC 4.7+, but I think it's mainly
> for C++11 support. When building Mesa with Clang 3.4 and 11-CURRENT's
> libc++, I had the following issues:
> 
> 1. Clang 3.4 fails to build Clover, see this PR:
>   https://bugs.freedesktop.org/show_bug.cgi?id=74098
> 
>   In the last comment, there's a patch to Clover, working around the
>   problem. Its author opened a ticket on LLVM bug tracker:
>   http://llvm.org/bugs/show_bug.cgi?id=18645

That PR has been languishing a little.  I'll see if I can get some
attention from the right people upstream. :)


> 2. Mesa's configure script is looking for stddef.h here:
>   /usr/local/llvm34/lib/clang/3.4/include
> 
>   LLVM/Clang ports don't install this file. I just added a symlink to
>   /usr/include/stddef.h and Mesa was happy. I still need to check how
>   it goes if I remove the check and the symlink. But perhaps Mesa is
>   right to expect this header (and maybe other) in this directory, I
>   don't know.

Clang provides its own version of a bunch of such headers, such as
stddef.h, stdarg.h, and so on, which conflict with our version in base
(e.g. /usr/include).  Therefore, the base version of clang does not
install these, and apparently, neither do the clang ports.

On the other hand, I don't really understand why Mesa wants to know
*where* a header is exactly located.  Normally, in configure scripts or
similar, you are only interested in whether the compiler can find it or
not.


> 3. Our base libc++ has a bug in the <functional> header. I posted a PR
>   on Mesa bug tracker here, before I found out it was a problem with
>   libc++:
>   https://bugs.freedesktop.org/show_bug.cgi?id=75505
> 
>   Apparently, it's fixed in libc++ upstream, in r199848.

I applied that fix to head in r262805, and I will MFC it after 3 days.


> 4. At runtime, any OpenCL program segfaults in libc++ (I don't have the
>   stack trace at hand and can't remember what it was... Something with
>   basic_string).
> 
> When using libc++ from ports (devel/libc++, r200683) and the work around
> for problem #1, Clover builds and OpenCL programs run fine.

Hm, this is unfortunate.  I'm interested in where the difference comes
from, and I would ideally like to fix any problem with libc++ in base.

Can you point me (privately if you like) to some info on how to build
and reproduce?

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20140305/c66cfd87/attachment.sig>