Re: Help. Porting FreeOCL fails (atomic_ops.h missing, CLANG++ libc++ issues ...)
Dimitry Andric d...@freebsd.org writes:
Now, as to how we can convince CMake to put the -I/usr/local/include at
the end... Maybe we should just patch the CMakeLists.txt, but that is a
rather ugly solution. :)
Try using
CPPFLAGS+=-isystem${LOCALBASE}/include
gcc(1) (and clang) has a flag for systems broken by design:
-isystem dir
Search dir for header files, after all directories specified by -I
but before the standard system directories. Mark it as a system
directory, so that it gets the same special treatment as is applied
to the standard system directories. If dir begins with =, then
the = will be replaced by the sysroot prefix; see --sysroot and
-isysroot.
For example, firefox uses it to avoid picking up lang/spidermonkey headers.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Help. Porting FreeOCL fails (atomic_ops.h missing, CLANG++ libc++ issues ...)
On Wed, 05 Sep 2012 16:45:49 +0200 O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: Hello. FreeBSD has fallen back far behind the standards of modern scientific computing and I dsperately look for solutions having OpenCL support on FreeBSD anyway. I stumbled into this project recently: FreeOCL at http://code.google.com/p/freeocl/ or the sources located at http://code.google.com/p/freeocl/downloads/detail?name=FreeOCL-0.3.6-src.tar.gzcan=2q= For your convenience, please find my naive attempt of a port attached to this email. Well, I tried LLVM/CLANG, but Cmake of the sources fairly fails many checks especuially for OpenMP. Using clang++ requisites the usage of the new libc++ (CXXFLAGS+= -stdlib=libc++). But this fails with this error: [...] [ 17%] Building CXX object src/CMakeFiles/FreeOCL.dir/codebuilder.cpp.o In file included from /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/codebuilder.cpp:26: /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/parser/parser.h:118:15: error: no viable conversion from 'std::__1::basic_istreamchar' to 'const bool' const bool ok = in.get(c); ^~ /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/codebuilder.cpp:444:13: warning: 70 enumeration values not handled in switch: 'VOID', 'BOOL', 'HALF'... [-Wswitch] switch(native-get_type_id()) ^ 1 warning and 1 error generated. *** [src/CMakeFiles/FreeOCL.dir/codebuilder.cpp.o] Error code 1 [..] I tried also setting USE_GCC= 4.7+ using gcc-4.7 I installed, but that fails with [...] -- Build files have been written to: /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source === Building for freeocl-0.3.6 Scanning dependencies of target FreeOCL [ 1%] Building CXX object src/CMakeFiles/FreeOCL.dir/freeocl.cpp.o In file included from /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/freeocl.cpp:18:0: /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/freeocl.h:71:2: error: 'u_int64_t' does not name a type *** [src/CMakeFiles/FreeOCL.dir/freeocl.cpp.o] Error code 1 [...] I think patches are required. More disturbing is the use of gcc-4.6 via USE_GCC= 4.6+ The error is then a compalin about a missing include file atomic_ops.h which is located in the abandoned KSE facility of the kernel, so the includes seem not to be installed anymore - but since I'm not involved in the development, I can only guess and ask the people here. Maybe some experienced freeBSD developers with the same need for OpenCl is willing to pick up this and help a bit. Well, as far as I see, the FreeOCL project of Roland Borchard is a OpenCL library for CPU usage. As far as I can understand, if we on FreeBSd could have a library libOpenCL as this is usually installed by the nVidia BLOB drivers on Linux for the use of OpenCL/GPGPU support with their GPUs, this would fill a still painfull open gap in FreeBSD as a scientific development platform. There is still no suitable compiler for OpenCL out here for freeBSD, but I have still the hope that LLVM can provide such a thing in the near future. I cross post this posting also to performance in the hope finding some people attracted and lurd into this subject. Regards, O. Hartmann Hello, I've taken a quick look in that implementation : it seems to depends on devel/libatomic_ops even if the devs did not write any CMake checks for that (grrr). After installing it, I was able to build the port with gcc-46 without problems, if I find some time, I will try to test it later. Btw, did you had a look to poCL too (http://sourceforge.net/apps/mediawiki/pocl/index.php?title=Main_Page)? I know the Debian people were considering it for a base implementation, but I'm a bit clueless about all those foss versions coming. A comparison could be helpful ^^ -- Matthieu Volat ma...@alkumuna.eu ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Help. Porting FreeOCL fails (atomic_ops.h missing, CLANG++ libc++ issues ...)
On 09/06/12 12:16, Matthieu Volat wrote: On Wed, 05 Sep 2012 16:45:49 +0200 O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: Hello. FreeBSD has fallen back far behind the standards of modern scientific computing and I dsperately look for solutions having OpenCL support on FreeBSD anyway. I stumbled into this project recently: FreeOCL at http://code.google.com/p/freeocl/ or the sources located at http://code.google.com/p/freeocl/downloads/detail?name=FreeOCL-0.3.6-src.tar.gzcan=2q= For your convenience, please find my naive attempt of a port attached to this email. Well, I tried LLVM/CLANG, but Cmake of the sources fairly fails many checks especuially for OpenMP. Using clang++ requisites the usage of the new libc++ (CXXFLAGS+= -stdlib=libc++). But this fails with this error: [...] [ 17%] Building CXX object src/CMakeFiles/FreeOCL.dir/codebuilder.cpp.o In file included from /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/codebuilder.cpp:26: /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/parser/parser.h:118:15: error: no viable conversion from 'std::__1::basic_istreamchar' to 'const bool' const bool ok = in.get(c); ^~ /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/codebuilder.cpp:444:13: warning: 70 enumeration values not handled in switch: 'VOID', 'BOOL', 'HALF'... [-Wswitch] switch(native-get_type_id()) ^ 1 warning and 1 error generated. *** [src/CMakeFiles/FreeOCL.dir/codebuilder.cpp.o] Error code 1 [..] I tried also setting USE_GCC= 4.7+ using gcc-4.7 I installed, but that fails with [...] -- Build files have been written to: /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source === Building for freeocl-0.3.6 Scanning dependencies of target FreeOCL [ 1%] Building CXX object src/CMakeFiles/FreeOCL.dir/freeocl.cpp.o In file included from /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/freeocl.cpp:18:0: /usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/freeocl.h:71:2: error: 'u_int64_t' does not name a type *** [src/CMakeFiles/FreeOCL.dir/freeocl.cpp.o] Error code 1 [...] I think patches are required. More disturbing is the use of gcc-4.6 via USE_GCC= 4.6+ The error is then a compalin about a missing include file atomic_ops.h which is located in the abandoned KSE facility of the kernel, so the includes seem not to be installed anymore - but since I'm not involved in the development, I can only guess and ask the people here. Maybe some experienced freeBSD developers with the same need for OpenCl is willing to pick up this and help a bit. Well, as far as I see, the FreeOCL project of Roland Borchard is a OpenCL library for CPU usage. As far as I can understand, if we on FreeBSd could have a library libOpenCL as this is usually installed by the nVidia BLOB drivers on Linux for the use of OpenCL/GPGPU support with their GPUs, this would fill a still painfull open gap in FreeBSD as a scientific development platform. There is still no suitable compiler for OpenCL out here for freeBSD, but I have still the hope that LLVM can provide such a thing in the near future. I cross post this posting also to performance in the hope finding some people attracted and lurd into this subject. Regards, O. Hartmann Hello, I've taken a quick look in that implementation : it seems to depends on devel/libatomic_ops even if the devs did not write any CMake checks for that (grrr). After installing it, I was able to build the port with gcc-46 without problems, if I find some time, I will try to test it later. Btw, did you had a look to poCL too (http://sourceforge.net/apps/mediawiki/pocl/index.php?title=Main_Page)? I know the Debian people were considering it for a base implementation, but I'm a bit clueless about all those foss versions coming. A comparison could be helpful ^^ Hello Matthieu. Thanks for the hint for that port. I will have a look at poCL. Thanks for that hint. I cross post to current, maybe those aspects have influence of some add ons in CURRENT in the future. Oliver signature.asc Description: OpenPGP digital signature
Re: Help. Porting FreeOCL fails (atomic_ops.h missing, CLANG++ libc++ issues ...)
On 09/06/12 12:16, Matthieu Volat wrote:
On Wed, 05 Sep 2012 16:45:49 +0200
O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote:
Hello.
FreeBSD has fallen back far behind the standards of modern scientific
computing and I dsperately look for solutions having OpenCL support on
FreeBSD anyway.
I stumbled into this project recently:
FreeOCL at
http://code.google.com/p/freeocl/
or the sources located at
http://code.google.com/p/freeocl/downloads/detail?name=FreeOCL-0.3.6-src.tar.gzcan=2q=
For your convenience, please find my naive attempt of a port attached to
this email.
Well, I tried LLVM/CLANG, but Cmake of the sources fairly fails many
checks especuially for OpenMP. Using clang++ requisites the usage of the
new libc++ (CXXFLAGS+= -stdlib=libc++). But this fails with this error:
[...]
[ 17%] Building CXX object src/CMakeFiles/FreeOCL.dir/codebuilder.cpp.o
In file included from
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/codebuilder.cpp:26:
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/parser/parser.h:118:15:
error: no viable conversion from 'std::__1::basic_istreamchar' to
'const bool'
const bool ok = in.get(c);
^~
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/codebuilder.cpp:444:13:
warning: 70 enumeration values not handled in switch: 'VOID', 'BOOL',
'HALF'... [-Wswitch]
switch(native-get_type_id())
^
1 warning and 1 error generated.
*** [src/CMakeFiles/FreeOCL.dir/codebuilder.cpp.o] Error code 1
[..]
I tried also setting USE_GCC= 4.7+ using gcc-4.7 I installed, but that
fails with
[...]
-- Build files have been written to:
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source
=== Building for freeocl-0.3.6
Scanning dependencies of target FreeOCL
[ 1%] Building CXX object src/CMakeFiles/FreeOCL.dir/freeocl.cpp.o
In file included from
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/freeocl.cpp:18:0:
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/freeocl.h:71:2:
error: 'u_int64_t' does not name a type
*** [src/CMakeFiles/FreeOCL.dir/freeocl.cpp.o] Error code 1
[...]
I think patches are required.
More disturbing is the use of gcc-4.6 via
USE_GCC= 4.6+
The error is then a compalin about a missing include file
atomic_ops.h
which is located in the abandoned KSE facility of the kernel, so the
includes seem not to be installed anymore - but since I'm not involved
in the development, I can only guess and ask the people here.
Maybe some experienced freeBSD developers with the same need for OpenCl
is willing to pick up this and help a bit.
Well, as far as I see, the FreeOCL project of Roland Borchard is a
OpenCL library for CPU usage. As far as I can understand, if we on
FreeBSd could have a library libOpenCL as this is usually installed by
the nVidia BLOB drivers on Linux for the use of OpenCL/GPGPU support
with their GPUs, this would fill a still painfull open gap in FreeBSD as
a scientific development platform.
There is still no suitable compiler for OpenCL out here for freeBSD, but
I have still the hope that LLVM can provide such a thing in the near future.
I cross post this posting also to performance in the hope finding some
people attracted and lurd into this subject.
Regards,
O. Hartmann
Hello,
I've taken a quick look in that implementation : it seems to depends on
devel/libatomic_ops even if the devs did not write any CMake checks for that
(grrr).
After installing it, I was able to build the port with gcc-46 without
problems, if I find some time, I will try to test it later.
Btw, did you had a look to poCL too
(http://sourceforge.net/apps/mediawiki/pocl/index.php?title=Main_Page)? I
know the Debian people were considering it for a base implementation, but I'm
a bit clueless about all those foss versions coming. A comparison could be
helpful ^^
I tried to add
RUN_DEPENDS=
${LOCALBASE}/lib/libatomic_ops.a:${PORTSDIR}/devel/libatomic_ops
to my provided Makefile, but this doesn't install the port
devel/libatomic_ops.
This is weird and inconsistent. I follow exact the steps suggested in
the Porter's handbook, the _DEPENDS= section. The above RUN_DEPENDS= tag
should ensure a check for the existence of the static library
/usr/local/lib/libatomic_ops.a
and if not existent, then install it. It doesn't work. Unfortunately,
LIB_DEPENDS is considered for shared libraries, so it isn't suitable.
But LIB_DEPENDS get recognized, even if it fails, while RUN_DEPENDS
seems not to be touched by the build process anyway ...
signature.asc
Description: OpenPGP digital signature
Re: Help. Porting FreeOCL fails (atomic_ops.h missing, CLANG++ libc++ issues ...)
On 09/06/12 13:33, Kurt Jaeger wrote:
Hi!
RUN_DEPENDS=
${LOCALBASE}/lib/libatomic_ops.a:${PORTSDIR}/devel/libatomic_ops
Why did you not add it as LIB_DEPENDS or BUILD_DEPENDS ?
Btw, any static library is always linked into the binary and
therefore can by definition not be a RUN_DEPENDS, but always is
a BUILD_DEPENDS.
Snakepit of logic :-( Sorry. BUILD_DEPENDS does the work as expected.
Thanks.
Oliver
signature.asc
Description: OpenPGP digital signature
Re: Help. Porting FreeOCL fails (atomic_ops.h missing, CLANG++ libc++ issues ...)
On 2012-09-05 16:45, O. Hartmann wrote:
...
Well, I tried LLVM/CLANG, but Cmake of the sources fairly fails many
checks especuially for OpenMP.
Yes, it is currently not supported. I am not sure if there are serious
attempts to add it.
Using clang++ requisites the usage of the
new libc++ (CXXFLAGS+= -stdlib=libc++). But this fails with this error:
...
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/parser/parser.h:118:15:
error: no viable conversion from 'std::__1::basic_istreamchar' to
'const bool'
const bool ok = in.get(c);
^~
This is a bug in FreeOCL. The istream::get() function returns an
istream reference, which can't be cast directly to bool. However, there
is a negation operator defined for istream, so the line can be changed
to:
const bool ok = !!in.get(c);
I have attached a patch for the port as I have built it here with clang.
I didn't add the dependency on atomic_ops yet, but it should be fairly
trivial.
Note I also needed a fix for Mk/bsd.cmake.mk, otherwise the required
${CPPFLAGS} would not be passed along to CMake, and then the build would
still fail to find the atomic_ops headers in /usr/local/include.
Index: Mk/bsd.cmake.mk
===
--- Mk/bsd.cmake.mk (revision 303593)
+++ Mk/bsd.cmake.mk (working copy)
@@ -50,12 +50,12 @@ BUILD_DEPENDS+= ${CMAKE_BIN}:${CMAKE_PORT}
CMAKE_ENV?= ${CONFIGURE_ENV}
CMAKE_ARGS+= -DCMAKE_C_COMPILER:STRING=${CC} \
-DCMAKE_CXX_COMPILER:STRING=${CXX} \
--DCMAKE_C_FLAGS:STRING=${CFLAGS} \
--DCMAKE_C_FLAGS_DEBUG:STRING=${CFLAGS} \
--DCMAKE_C_FLAGS_RELEASE:STRING=${CFLAGS} \
--DCMAKE_CXX_FLAGS:STRING=${CXXFLAGS} \
--DCMAKE_CXX_FLAGS_DEBUG:STRING=${CXXFLAGS} \
--DCMAKE_CXX_FLAGS_RELEASE:STRING=${CXXFLAGS} \
+-DCMAKE_C_FLAGS:STRING=${CPPFLAGS} ${CFLAGS} \
+-DCMAKE_C_FLAGS_DEBUG:STRING=${CPPFLAGS} ${CFLAGS} \
+-DCMAKE_C_FLAGS_RELEASE:STRING=${CPPFLAGS} ${CFLAGS} \
+-DCMAKE_CXX_FLAGS:STRING=${CPPFLAGS} ${CXXFLAGS} \
+-DCMAKE_CXX_FLAGS_DEBUG:STRING=${CPPFLAGS} ${CXXFLAGS} \
+-DCMAKE_CXX_FLAGS_RELEASE:STRING=${CPPFLAGS} ${CXXFLAGS} \
-DCMAKE_EXE_LINKER_FLAGS:STRING=${LDFLAGS} \
-DCMAKE_MODULE_LINKER_FLAGS:STRING=${LDFLAGS} \
-DCMAKE_SHARED_LINKER_FLAGS:STRING=${LDFLAGS} \
Index: devel/freeocl/Makefile
===
--- devel/freeocl/Makefile (revision 0)
+++ devel/freeocl/Makefile (working copy)
@@ -0,0 +1,22 @@
+PORTNAME= freeocl
+PORTVERSION= 0.3.6
+CATEGORIES= devel
+
+MAINTAINER= po...@freebsd.org
+COMMENT= FreeOCL - a free OpenCL implementation for CPU
+
+#MASTER_SITES= http://freeocl.googlecode.com/files/FreeOCL-0.3.6-src.tar.gz
+MASTER_SITES= http://freeocl.googlecode.com/files/
+DISTNAME= FreeOCL-${PORTVERSION}-src
+
+WRKSRC= ${WRKDIR}/FreeOCL-${PORTVERSION}-Source
+
+USE_CMAKE= YES
+CMAKE_BUILD_TYPE= Release
+
+#USE_GCC= 4.7+
+
+CPPFLAGS+= -I${LOCALBASE}/include
+CXXFLAGS+= -stdlib=libc++
+
+.include bsd.port.mk
Index: devel/freeocl/files/patch-src__parser__parser.h
===
--- devel/freeocl/files/patch-src__parser__parser.h (revision 0)
+++ devel/freeocl/files/patch-src__parser__parser.h (working copy)
@@ -0,0 +1,11 @@
+--- src/parser/parser.h.orig 2012-09-02 19:00:41.0 +0200
src/parser/parser.h 2012-09-06 14:14:01.0 +0200
+@@ -115,7 +115,7 @@ namespace FreeOCL
+ inline std::istream get(char c)
+ {
+ c = 0;
+- const bool ok = in.get(c);
++ const bool ok = !!in.get(c);
+ if (c == '\n')
+ ++line;
+ if (!current_line.empty() *current_line.rbegin() == '\n')
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Help. Porting FreeOCL fails (atomic_ops.h missing, CLANG++ libc++ issues ...)
On Thu, 2012-09-06 at 13:14 +0200, O. Hartmann wrote:
I tried to add
RUN_DEPENDS=
${LOCALBASE}/lib/libatomic_ops.a:${PORTSDIR}/devel/libatomic_ops
to my provided Makefile, but this doesn't install the port
devel/libatomic_ops.
This is weird and inconsistent. I follow exact the steps suggested in
the Porter's handbook, the _DEPENDS= section. The above RUN_DEPENDS=
tag
should ensure a check for the existence of the static library
/usr/local/lib/libatomic_ops.a
and if not existent, then install it. It doesn't work. Unfortunately,
LIB_DEPENDS is considered for shared libraries, so it isn't
suitable.
But LIB_DEPENDS get recognized, even if it fails, while RUN_DEPENDS
seems not to be touched by the build process anyway ...
I am SO not a ports expert, but I think maybe for a static lib you need
BUILD_DEPENDS because it has to be available at build-time rather than
run-time.
-- Ian
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Help. Porting FreeOCL fails (atomic_ops.h missing, CLANG++ libc++ issues ...)
Hello Dimitry,
thanks for your response and patches.
On 09/06/12 14:51, Dimitry Andric wrote:
On 2012-09-05 16:45, O. Hartmann wrote:
...
Well, I tried LLVM/CLANG, but Cmake of the sources fairly fails many
checks especuially for OpenMP.
Yes, it is currently not supported. I am not sure if there are serious
attempts to add it.
Using clang++ requisites the usage of the
new libc++ (CXXFLAGS+= -stdlib=libc++). But this fails with this error:
...
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/parser/parser.h:118:15:
error: no viable conversion from 'std::__1::basic_istreamchar' to
'const bool'
const bool ok = in.get(c);
^~
This is a bug in FreeOCL. The istream::get() function returns an
istream reference, which can't be cast directly to bool. However, there
is a negation operator defined for istream, so the line can be changed
to:
const bool ok = !!in.get(c);
I have attached a patch for the port as I have built it here with clang.
I didn't add the dependency on atomic_ops yet, but it should be fairly
trivial.
I fixed that, I forgot the pkg-plist, also. Will followup the PR I sent.
it is a simple line:
BUILD_DEPENDS= ...
Note I also needed a fix for Mk/bsd.cmake.mk, otherwise the required
${CPPFLAGS} would not be passed along to CMake, and then the build would
still fail to find the atomic_ops headers in /usr/local/include.
Is this going to be fixed with your patch in the ports tree?
I'm amazed by the speed you came up with the patches ...;-)
My port request can be found here:
http://www.freebsd.org/cgi/query-pr.cgi?pr=171376
and one for providing the OpenCL header:
http://www.freebsd.org/cgi/query-pr.cgi?pr=171375
Matthieu Volat also stated that there is another promising OpenCL port
Portable OpenCL, pocl. It seems to have a better LLVM support by design:
http://sourceforge.net/apps/mediawiki/pocl/index.php?title=Main_Page
Attached you'll find my first naiv attempt to build a port-Makefile, but
I fail to fetch(1), since there is an authentication error while trying
to fetch from a HTTPS:// source.
My abilities in depp-insight-development are limited, so I'm happy if
some experienced developers could also look at those software projects
and help making a port ;-)
it would be nice having FreeOCL and portable OCL for comparison purposes
available on FreeBSD. I still have the hope to lurd more developers
and scientists back to FreeBSD. Never mind ...
oh
PORTNAME= pocl
PORTVERSION=0.6
CATEGORIES= devel
MAINTAINER= po...@freebsd.org
COMMENT=Portable OpenCL - an efficient open source
(MIT-licensed) implementation of the OpenCL 1.2 standard.
MASTER_SITES=
https://launchpad.net/pocl/${PORTVERSION}/0.6.0/+download/
#CONFLICTS= freeocl
CXXFLAGS+= -stdlib=libc++
LIB_DEPENDS=ltdl:${PORTSDIR}/devel/libltdl
#USE_GMAKE= yes
GNU_CONFIGURE= yes
USE_LDCONFIG= yes
.include bsd.port.mk
signature.asc
Description: OpenPGP digital signature
Re: Help. Porting FreeOCL fails (atomic_ops.h missing, CLANG++ libc++ issues ...)
On 09/06/12 14:51, Dimitry Andric wrote:
On 2012-09-05 16:45, O. Hartmann wrote:
...
Well, I tried LLVM/CLANG, but Cmake of the sources fairly fails many
checks especuially for OpenMP.
Yes, it is currently not supported. I am not sure if there are serious
attempts to add it.
Using clang++ requisites the usage of the
new libc++ (CXXFLAGS+= -stdlib=libc++). But this fails with this error:
...
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/parser/parser.h:118:15:
error: no viable conversion from 'std::__1::basic_istreamchar' to
'const bool'
const bool ok = in.get(c);
^~
This is a bug in FreeOCL. The istream::get() function returns an
istream reference, which can't be cast directly to bool. However, there
is a negation operator defined for istream, so the line can be changed
to:
const bool ok = !!in.get(c);
I have attached a patch for the port as I have built it here with clang.
I didn't add the dependency on atomic_ops yet, but it should be fairly
trivial.
Note I also needed a fix for Mk/bsd.cmake.mk, otherwise the required
${CPPFLAGS} would not be passed along to CMake, and then the build would
still fail to find the atomic_ops headers in /usr/local/include.
With the patch for Mk/bsd.cmake.mk attached, I can not compile the port
with CLANG, compilation results in
[ 15%] Building CXX object src/CMakeFiles/FreeOCL.dir/image.cpp.o
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/image.cpp:442:27:
error: member access into incomplete type 'struct _cl_event'
if (event_wait_list[i]-status 0)
^
/usr/local/include/CL/cl.h:46:16: note: forward declaration of '_cl_event'
typedef struct _cl_event * cl_event;
^
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/image.cpp:449:58:
error: allocation of incomplete type '_cl_event'
cmd-event = (blocking_read == CL_TRUE || event) ? new
_cl_event(command_queue-context) : NULL;
^
/usr/local/include/CL/cl.h:46:16: note: forward declaration of '_cl_event'
typedef struct _cl_event * cl_event;
^
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/image.cpp:463:14:
error: member access into incomplete type '_cl_event'
cmd-event-command_queue = command_queue;
^
/usr/local/include/CL/cl.h:46:16: note: forward declaration of '_cl_event'
typedef struct _cl_event * cl_event;
^
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/image.cpp:464:14:
error: member access into incomplete type '_cl_event'
cmd-event-command_type = CL_COMMAND_READ_IMAGE;
^
/usr/local/include/CL/cl.h:46:16: note: forward declaration of '_cl_event'
typedef struct _cl_event * cl_event;
Without the patch, CLANG++ doesn't find the atomic_ops.h header as you
wrote.
Oliver
signature.asc
Description: OpenPGP digital signature
Re: Help. Porting FreeOCL fails (atomic_ops.h missing, CLANG++ libc++ issues ...)
On 2012-09-06 20:28, O. Hartmann wrote:
...
With the patch for Mk/bsd.cmake.mk attached, I can not compile the port
with CLANG, compilation results in
[ 15%] Building CXX object src/CMakeFiles/FreeOCL.dir/image.cpp.o
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/image.cpp:442:27:
error: member access into incomplete type 'struct _cl_event'
if (event_wait_list[i]-status 0)
^
/usr/local/include/CL/cl.h:46:16: note: forward declaration of '_cl_event'
typedef struct _cl_event * cl_event;
^
Which package installed that /usr/local/include/CL/cl.h file? It looks
like it should take this header from the source package, not from
whatever is installed into /usr/local.
In the top-level CMakeLists.txt, there is this fragment:
include_directories(.)
include_directories(include)
include_directories(src)
which indicates to CMake it should add -I flags for each of those
directories. However, it seems -I/usr/local/include is placed earlier
in the arguments of the actual clang++ invocations:
/usr/bin/clang++ -DFreeOCL_EXPORTS -O2 -pipe -I/usr/local/include
-fno-strict-aliasing -I/usr/local/include -stdlib=libc++ -std=c++0x
-DFREEOCL_USE_CXX0X -DFREEOCL_ARCH_amd64 -O3 -ffast-math -fPIC
-I/usr/work/share/dim/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/.
-I/usr/work/share/dim/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/include
-I/usr/work/share/dim/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src
-o CMakeFiles/FreeOCL.dir/image.cpp.o -c
/usr/work/share/dim/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/image.cpp
So it will take /usr/local/include/CL/cl.h before the cl.h under
${WRKSRC}.
Now, as to how we can convince CMake to put the -I/usr/local/include at
the end... Maybe we should just patch the CMakeLists.txt, but that is a
rather ugly solution. :)
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Help. Porting FreeOCL fails (atomic_ops.h missing, CLANG++ libc++ issues ...)
Hello.
FreeBSD has fallen back far behind the standards of modern scientific
computing and I dsperately look for solutions having OpenCL support on
FreeBSD anyway.
I stumbled into this project recently:
FreeOCL at
http://code.google.com/p/freeocl/
or the sources located at
http://code.google.com/p/freeocl/downloads/detail?name=FreeOCL-0.3.6-src.tar.gzcan=2q=
For your convenience, please find my naive attempt of a port attached to
this email.
Well, I tried LLVM/CLANG, but Cmake of the sources fairly fails many
checks especuially for OpenMP. Using clang++ requisites the usage of the
new libc++ (CXXFLAGS+= -stdlib=libc++). But this fails with this error:
[...]
[ 17%] Building CXX object src/CMakeFiles/FreeOCL.dir/codebuilder.cpp.o
In file included from
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/codebuilder.cpp:26:
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/parser/parser.h:118:15:
error: no viable conversion from 'std::__1::basic_istreamchar' to
'const bool'
const bool ok = in.get(c);
^~
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/codebuilder.cpp:444:13:
warning: 70 enumeration values not handled in switch: 'VOID', 'BOOL',
'HALF'... [-Wswitch]
switch(native-get_type_id())
^
1 warning and 1 error generated.
*** [src/CMakeFiles/FreeOCL.dir/codebuilder.cpp.o] Error code 1
[..]
I tried also setting USE_GCC= 4.7+ using gcc-4.7 I installed, but that
fails with
[...]
-- Build files have been written to:
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source
=== Building for freeocl-0.3.6
Scanning dependencies of target FreeOCL
[ 1%] Building CXX object src/CMakeFiles/FreeOCL.dir/freeocl.cpp.o
In file included from
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/freeocl.cpp:18:0:
/usr/ports/devel/freeocl/work/FreeOCL-0.3.6-Source/src/freeocl.h:71:2:
error: 'u_int64_t' does not name a type
*** [src/CMakeFiles/FreeOCL.dir/freeocl.cpp.o] Error code 1
[...]
I think patches are required.
More disturbing is the use of gcc-4.6 via
USE_GCC= 4.6+
The error is then a compalin about a missing include file
atomic_ops.h
which is located in the abandoned KSE facility of the kernel, so the
includes seem not to be installed anymore - but since I'm not involved
in the development, I can only guess and ask the people here.
Maybe some experienced freeBSD developers with the same need for OpenCl
is willing to pick up this and help a bit.
Well, as far as I see, the FreeOCL project of Roland Borchard is a
OpenCL library for CPU usage. As far as I can understand, if we on
FreeBSd could have a library libOpenCL as this is usually installed by
the nVidia BLOB drivers on Linux for the use of OpenCL/GPGPU support
with their GPUs, this would fill a still painfull open gap in FreeBSD as
a scientific development platform.
There is still no suitable compiler for OpenCL out here for freeBSD, but
I have still the hope that LLVM can provide such a thing in the near future.
I cross post this posting also to performance in the hope finding some
people attracted and lurd into this subject.
Regards,
O. Hartmann
PORTNAME= freeocl
PORTVERSION=0.3.6
CATEGORIES= devel
MAINTAINER= po...@freebsd.org
COMMENT=FreeOCL - a free OpenCL implementation for CPU
#MASTER_SITES=
http://freeocl.googlecode.com/files/FreeOCL-0.3.6-src.tar.gz
MASTER_SITES= http://freeocl.googlecode.com/files/
DISTNAME= FreeOCL-${PORTVERSION}-src
WRKSRC= ${WRKDIR}/FreeOCL-${PORTVERSION}-Source
USE_CMAKE= YES
CMAKE_BUILD_TYPE= Release
USE_GCC=4.7+
#CXXFLAGS+= -stdlib=libc++
.include bsd.port.mk
signature.asc
Description: OpenPGP digital signature
