clang/llvm: /usr/local/include in port base system not standard? (port devel/freeocl)

[O. Hartmann]

Am 12/24/12 21:35, schrieb Dimitry Andric:
> On 2012-12-24 18:10, O. Hartmann wrote:
>> Some ports (devel/freeocl for instance) won't compile easily with CLANG.
>> I fugured out that sometimes CLANG is not by default including
>> /usr/local/include into the CPP search path - obviously gcc/gcc46 does!
> 
> Eh, that is incorrect.  The version of gcc in base does *not* have
> /usr/local/include in its default include path, and our version of clang
> in base mimics that behaviour.  I know this has been a point of much
> discussion, but I don't want to repeat any of it here; just stating the
> facts.

Not necessary to repeat, I think I can believe your words. Thank you
very much.

> 
> I don't know precisely what the port versions of gcc and clang do,
> however.  It is a Linuxism to always have /usr/local/include in the
> default path, so it may well be that the port versions do this too.
> 
> 
>> Well, I feel a bit confused, since I do not know how to manage the
>> intransparent port framework (intransparent to me) to force the port's
>> Makefile to include via "-I/usr/local/include" the path in question.
> 
> Like it is done in most ports, try adding:
> 
> CPPFLAGS+=    -I${LOCALBASE}/include
> LDFLAGS+=    -L${LOCALBASE}/lib

I already did this. And it didn't work for me.

> 
> 
>> By the way, the build backend is cmake which I'm completely unfamiliar
>> with. Can someone give a hint?
> 
> CMake has its own logic for searching headers, but I am not sure what
> the correct solution is for your specific project.

Well, it is the devel/freeocl project. I used the tag

USE_GCC=4.6+

in the Makefile and realised that with gcc47 it will not compile
anymore, so using simply USE_GCC=4.6+ seems dangerous and incorrect to me.

I then tried to compile the FreeOCL library with CLANG 3.1 and 3.2.
CLANG fails in src/parser/parser.h, line 118. The righthand value needs
to be casted to (bool), otherwise CLANG complains and spite fire ...

In src/utils/threadpool.cpp, the #include <atomic_ops.h> fails, since it
is located in /usr/local/include. By brute-force I set it to the
absolute path </usr/local/inlcude/atomic_ops.h>. Then it compiles with
CLANG.

The port also requires having set CXXFLAGS+= -stdlib=libc++, otherwise
there is another issue with a header located in tr1 and not found by
CLANG by default.

If someone do not necessarily need OpenMP, then the port can be compiled
with the changes on both FreeBSD 9.1 and 10.0. On 9.1 the new
LIBCPLUSPLUS option needs to be available - I do not nknow how to handle
this cleanly.

Well, I will look for the Cmake thing, it might be possible to solve the
problem in a clean way, so I can provide an update for the port
devel/freeocl.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20121224/06906c42/attachment.sig>