CMake Process

[matusi143]

I just downloaded and attempted to the the latest version running using CMake. However, the make-file references a few things which I believe would need to be in my %PATH but I didn't want to do that as I change versions frequently. I tried to hard code them:

set(Boost_USE_STATIC_LIBS OFF) set(Boost_USE_MULTITHREADED ON) set(Boost_USE_STATIC_RUNTIME OFF)

find_package(Boost) _commented out in favor of the line below_

include_directories("C:/boost_1_54_0")

find OpenCL

findpackage(OpenCL REQUIRED) *commented out in favor of the lines below _*

include_directories(${OPENCL_INCLUDE_DIR}) link_directories(${OPENCL_LIBRARIES}) link_directories("C:/Users/matth_000/AMD APP SDK/2.9/lib/x86_64")

After these changes cmake appeared to run fine, although I was unsuccessful in getting the program to build in qt5. Perhaps I am missing some steps in the instructions.

If you could please provide more detailed steps for the cmake build process and provide either directions on how to use the find_package function or leave it as a build parameter it would be helpful.

[namikk]

Hi,

the default CMakeLists currently has significant issues with enabling OpenCL. I did my best to try and make it work, but until someone more experienced does it right I'm afraid there's nothing I can do. The furthest I got with setting it up on my machine are a couple of multiple definitions of OpenCL function and a mysterious file format not recognized error for OpenCL.dll. You can still use the old CMakeLists_Qt4 & 5 files if you want to run it without OpenCL.

Best regards, Namik

On Sun, Jun 29, 2014 at 8:09 PM, matusi143 notifications@github.com wrote:

I just downloaded and attempted to the the latest version running using CMake. However, the make-file references a few things which I believe would need to be in my %PATH but I didn't want to do that as I change versions frequently. I tried to hard code them:

set(Boost_USE_STATIC_LIBS OFF) set(Boost_USE_MULTITHREADED ON) set(Boost_USE_STATIC_RUNTIME OFF)

find_package(Boost) commented out in favor of the line below

include_directories("C:/boost_1_54_0")

find OpenCL

findpackage(OpenCL REQUIRED) **commented out in favor of the lines

below _ include_directories(${OPENCL_INCLUDE_DIR}) link_directories(${OPENCL_LIBRARIES}) link_directories("C:/Users/matth_000/AMD APP SDK/2.9/lib/x86_64")

After these changes cmake appeared to run fine, although I was unsuccessful in getting the program to build in qt5. Perhaps I am missing some steps in the instructions.

If you could please provide more detailed steps for the cmake build process and provide either directions on how to use the find_package function or leave it as a build parameter it would be helpful.

— Reply to this email directly or view it on GitHub https://github.com/viennacl/viennacl-benchmark-gui/issues/2.

[ptillet]

Hi,

According to the FindOpenCL.cmake, it should work either if: -> the environment variable OPENCLROOT is set -> OpenCL is installed in default directories : /usr/, /usr/local/

Personally, I've been using symbolic links to handle OpenCL including/linking.

Philippe

2014-06-30 0:12 GMT+02:00 Namik Karovic notifications@github.com:

Hi,

the default CMakeLists currently has significant issues with enabling OpenCL. I did my best to try and make it work, but until someone more experienced does it right I'm afraid there's nothing I can do. The furthest I got with setting it up on my machine are a couple of multiple definitions of OpenCL function and a mysterious file format not recognized error for OpenCL.dll. You can still use the old CMakeLists_Qt4 & 5 files if you want to run it without OpenCL.

Best regards, Namik

On Sun, Jun 29, 2014 at 8:09 PM, matusi143 notifications@github.com wrote:

I just downloaded and attempted to the the latest version running using CMake. However, the make-file references a few things which I believe would need to be in my %PATH but I didn't want to do that as I change versions frequently. I tried to hard code them:

set(Boost_USE_STATIC_LIBS OFF) set(Boost_USE_MULTITHREADED ON) set(Boost_USE_STATIC_RUNTIME OFF)

find_package(Boost) commented out in favor of the line below

include_directories("C:/boost_1_54_0")

find OpenCL

findpackage(OpenCL REQUIRED) **commented out in favor of the lines

below _ include_directories(${OPENCL_INCLUDE_DIR}) link_directories(${OPENCL_LIBRARIES}) link_directories("C:/Users/matth_000/AMD APP SDK/2.9/lib/x86_64")

After these changes cmake appeared to run fine, although I was unsuccessful in getting the program to build in qt5. Perhaps I am missing some steps in the instructions.

If you could please provide more detailed steps for the cmake build process and provide either directions on how to use the find_package function or leave it as a build parameter it would be helpful.

— Reply to this email directly or view it on GitHub https://github.com/viennacl/viennacl-benchmark-gui/issues/2.

— Reply to this email directly or view it on GitHub https://github.com/viennacl/viennacl-benchmark-gui/issues/2#issuecomment-47478783 .

[matusi143]

Namik, thank you for the update. I will wait for the next version. Do you plan on offering an interim release that will build so people can see the UI and offer feedback on the matrix market interface when that becomes available?

Phillipe, I am using Windows 8.1 so /usr won't work. Do you know how I can modify my %PATH to allow OPENCLROOT to work or is that Linux only as well?

[ptillet]

Hi,

I think it has nothing to do with the %PATH. You probably need to set the environment variable OPENCLROOT. The CMake script will look for. $ENV{OPENCLROOT}/include/ $ENV{OPENCLROOT}/lib/x86/ $ENV{OPENCLROOT}/lib/x86_64/ With cmake handling the proper delimiters on Windows.

If the environment variable OPENCLROOT is not set, the CMake script uses ATISTREAMSDKROOT, AMDAPPSDKROOT, INTELOCLSDKROOT. Some may be missing on newer SDKs. What SDK are you using? Does it set an environment variable for the path during the installation process?

Philipe

2014-06-30 2:25 GMT+02:00 matusi143 notifications@github.com:

Namik, thank you for the update. I will wait for the next version. Do you plan on offering an interim release that will build so people can see the UI and offer feedback on the matrix market interface when that becomes available?

Phillipe, I am using Windows 8.1 so /usr won't work. Do you know how I can modify my %PATH to allow OPENCLROOT to work or is that Linux only as well?

— Reply to this email directly or view it on GitHub https://github.com/viennacl/viennacl-benchmark-gui/issues/2#issuecomment-47486070 .

[karlrupp]

Philippe is right, this is all set through the environment variables in Windows, as this is the only way to automatically detect an OpenCL SDK. Have a look here: http://superuser.com/questions/502358/easier-way-to-change-environment-variables-in-windows-8 on how to do this. If your SDK uses a different variable name, please let us know so that we can update the OpenCL detection accordingly.

[namikk]

Hi,

I already tried setting OPENCLROOT, but it yielded the same results as any other attempt.

I get a couple of these: error: multiple definition of viennacl::linalg::double_float_conversion_program'; And a couple thousands of these: error: Cannot get section contents - auto-import exception; Resulting in this: :-1: error: CMakeFiles\ViennaCL_Benchmark.dir/objects.a(benchmark_solver.cpp.obj): bad reloc address 0x0 in section.data'

I have no idea what causes this.

Namik

On Mon, Jun 30, 2014 at 12:12 PM, PhilippeTillet notifications@github.com wrote:

Hi,

I think it has nothing to do with the %PATH. You probably need to set the environment variable OPENCLROOT. The CMake script will look for. $ENV{OPENCLROOT}/include/ $ENV{OPENCLROOT}/lib/x86/ $ENV{OPENCLROOT}/lib/x86_64/ With cmake handling the proper delimiters on Windows.

If the environment variable OPENCLROOT is not set, the CMake script uses ATISTREAMSDKROOT, AMDAPPSDKROOT, INTELOCLSDKROOT. Some may be missing on newer SDKs. What SDK are you using? Does it set an environment variable for the path during the installation process?

Philipe

2014-06-30 2:25 GMT+02:00 matusi143 notifications@github.com:

Namik, thank you for the update. I will wait for the next version. Do you plan on offering an interim release that will build so people can see the UI and offer feedback on the matrix market interface when that becomes available?

Phillipe, I am using Windows 8.1 so /usr won't work. Do you know how I can modify my %PATH to allow OPENCLROOT to work or is that Linux only as well?

— Reply to this email directly or view it on GitHub < https://github.com/viennacl/viennacl-benchmark-gui/issues/2#issuecomment-47486070>

.

— Reply to this email directly or view it on GitHub https://github.com/viennacl/viennacl-benchmark-gui/issues/2#issuecomment-47515324 .

[karlrupp]

The problem with double_float_conversion_program is fixed here: https://github.com/viennacl/viennacl-dev/commit/d47c8ab94b4f204573cca6fea1dd23e858e7098c (the source string accidentally had external linkage, hence the multiple definitions when you linked the object files together) The other error might stem from a missing -fPIC flag, yet it seems to be MinGW specific. Can you create a minimal example to reproduce the error?

[namikk]

Quick update,

It seems that the errors I mentioned appear only in the benchmark_solver. Disabling it completely removes the errors. I can now run the benchmark with OpenCL support on my GPU. There is definitely something fishy with solver benchmark (it causes the Heisenbug as well).

As for what I did to enable OpenCL: -installed AMD APP SDK 2.9 in a custom folder (C:\AMDAPPSDK); -removed all traces of OpenCL paths from the environment variables; -added environment variable OPENCLROOT to this custom folder (C:\AMDAPPSDK); -used FindOpenCL.cmake with CMake to find OpenCL automatically;

I'll update the CMakeLists file and Readme to better describe the build process.

Regards, Namik

On Mon, Jun 30, 2014 at 12:31 PM, Namik Karovic namik.karovic@gmail.com wrote:

Hi,

I already tried setting OPENCLROOT, but it yielded the same results as any other attempt.

I get a couple of these: error: multiple definition of viennacl::linalg::double_float_conversion_program'; And a couple thousands of these: error: Cannot get section contents - auto-import exception; Resulting in this: :-1: error: CMakeFiles\ViennaCL_Benchmark.dir/objects.a(benchmark_solver.cpp.obj): bad reloc address 0x0 in section.data'

I have no idea what causes this.

Namik

On Mon, Jun 30, 2014 at 12:12 PM, PhilippeTillet <notifications@github.com

wrote:

Hi,

I think it has nothing to do with the %PATH. You probably need to set the environment variable OPENCLROOT. The CMake script will look for. $ENV{OPENCLROOT}/include/ $ENV{OPENCLROOT}/lib/x86/ $ENV{OPENCLROOT}/lib/x86_64/ With cmake handling the proper delimiters on Windows.

If the environment variable OPENCLROOT is not set, the CMake script uses ATISTREAMSDKROOT, AMDAPPSDKROOT, INTELOCLSDKROOT. Some may be missing on newer SDKs. What SDK are you using? Does it set an environment variable for the path during the installation process?

Philipe

2014-06-30 2:25 GMT+02:00 matusi143 notifications@github.com:

Namik, thank you for the update. I will wait for the next version. Do you plan on offering an interim release that will build so people can see the UI and offer feedback on the matrix market interface when that becomes available?

Phillipe, I am using Windows 8.1 so /usr won't work. Do you know how I can modify my %PATH to allow OPENCLROOT to work or is that Linux only as well?

— Reply to this email directly or view it on GitHub < https://github.com/viennacl/viennacl-benchmark-gui/issues/2#issuecomment-47486070>

.

— Reply to this email directly or view it on GitHub https://github.com/viennacl/viennacl-benchmark-gui/issues/2#issuecomment-47515324 .

[namikk]

Hi,

The problem with double_float_conversion_program is fixed here: viennacl/viennacl-dev@d47c8ab

https://github.com/viennacl/viennacl-dev/commit/d47c8ab94b4f204573cca6fea1dd23e858e7098c(the source string accidentally had external linkage, hence the multiple definitions when you linked the object files together) The other error might stem from a missing -fPIC flag, yet it seems to be MinGW specific. Can you create a minimal example to reproduce the error?

This reminded me that I haven't updated my local ViennaCL repo for quite some time. Now that I got the latest version, the version that work with OpenCL a moment ago fails to compile with the following errors:

1. ..\viennacl-dev\viennacl\ocl\kernel.hpp:241: error: request for member 'handle' in 'val', which is of non-class type 'const long int' cl_mem temp = val.handle().opencl_handle().get();
2. ..\viennacl-dev\viennacl\ocl\kernel.hpp:241: error: request for member 'handle' in 'val', which is of non-class type 'const long unsigned int';

These new errors seem oddly familiar, but I don't know what needs to be done to fix them.

Namik

On Mon, Jun 30, 2014 at 12:42 PM, Namik Karovic namik.karovic@gmail.com wrote:

Quick update,

It seems that the errors I mentioned appear only in the benchmark_solver. Disabling it completely removes the errors. I can now run the benchmark with OpenCL support on my GPU. There is definitely something fishy with solver benchmark (it causes the Heisenbug as well).

As for what I did to enable OpenCL: -installed AMD APP SDK 2.9 in a custom folder (C:\AMDAPPSDK); -removed all traces of OpenCL paths from the environment variables; -added environment variable OPENCLROOT to this custom folder (C:\AMDAPPSDK); -used FindOpenCL.cmake with CMake to find OpenCL automatically;

I'll update the CMakeLists file and Readme to better describe the build process.

Regards, Namik

On Mon, Jun 30, 2014 at 12:31 PM, Namik Karovic namik.karovic@gmail.com wrote:

Hi,

I already tried setting OPENCLROOT, but it yielded the same results as any other attempt.

I get a couple of these: error: multiple definition of viennacl::linalg::double_float_conversion_program'; And a couple thousands of these: error: Cannot get section contents - auto-import exception; Resulting in this: :-1: error: CMakeFiles\ViennaCL_Benchmark.dir/objects.a(benchmark_solver.cpp.obj): bad reloc address 0x0 in section.data'

I have no idea what causes this.

Namik

On Mon, Jun 30, 2014 at 12:12 PM, PhilippeTillet < notifications@github.com> wrote:

Hi,

I think it has nothing to do with the %PATH. You probably need to set the environment variable OPENCLROOT. The CMake script will look for. $ENV{OPENCLROOT}/include/ $ENV{OPENCLROOT}/lib/x86/ $ENV{OPENCLROOT}/lib/x86_64/ With cmake handling the proper delimiters on Windows.

If the environment variable OPENCLROOT is not set, the CMake script uses ATISTREAMSDKROOT, AMDAPPSDKROOT, INTELOCLSDKROOT. Some may be missing on newer SDKs. What SDK are you using? Does it set an environment variable for the path during the installation process?

Philipe

2014-06-30 2:25 GMT+02:00 matusi143 notifications@github.com:

Namik, thank you for the update. I will wait for the next version. Do you plan on offering an interim release that will build so people can see the UI and offer feedback on the matrix market interface when that becomes available?

Phillipe, I am using Windows 8.1 so /usr won't work. Do you know how I can modify my %PATH to allow OPENCLROOT to work or is that Linux only as well?

— Reply to this email directly or view it on GitHub < https://github.com/viennacl/viennacl-benchmark-gui/issues/2#issuecomment-47486070>

.

— Reply to this email directly or view it on GitHub https://github.com/viennacl/viennacl-benchmark-gui/issues/2#issuecomment-47515324 .

[ptillet]

Hi Namik,

Can you reset before my Sat Jun 28th commit and retry? I pushed some big changes, which have not yet been tested on windows.

Philippe

2014-06-30 13:30 GMT+02:00 Namik Karovic notifications@github.com:

Hi,

The problem with double_float_conversion_program is fixed here: viennacl/viennacl-dev@d47c8ab

< https://github.com/viennacl/viennacl-dev/commit/d47c8ab94b4f204573cca6fea1dd23e858e7098c>(the

source string accidentally had external linkage, hence the multiple definitions when you linked the object files together) The other error might stem from a missing -fPIC flag, yet it seems to be MinGW specific. Can you create a minimal example to reproduce the error?

This reminded me that I haven't updated my local ViennaCL repo for quite some time. Now that I got the latest version, the version that work with OpenCL a moment ago fails to compile with the following errors:

1. ..\viennacl-dev\viennacl\ocl\kernel.hpp:241: error: request for member 'handle' in 'val', which is of non-class type 'const long int' cl_mem temp = val.handle().opencl_handle().get();
2. ..\viennacl-dev\viennacl\ocl\kernel.hpp:241: error: request for member 'handle' in 'val', which is of non-class type 'const long unsigned int';

These new errors seem oddly familiar, but I don't know what needs to be done to fix them.

Namik

On Mon, Jun 30, 2014 at 12:42 PM, Namik Karovic namik.karovic@gmail.com wrote:

Quick update,

It seems that the errors I mentioned appear only in the benchmark_solver. Disabling it completely removes the errors. I can now run the benchmark with OpenCL support on my GPU. There is definitely something fishy with solver benchmark (it causes the Heisenbug as well).

As for what I did to enable OpenCL: -installed AMD APP SDK 2.9 in a custom folder (C:\AMDAPPSDK); -removed all traces of OpenCL paths from the environment variables; -added environment variable OPENCLROOT to this custom folder (C:\AMDAPPSDK); -used FindOpenCL.cmake with CMake to find OpenCL automatically;

I'll update the CMakeLists file and Readme to better describe the build process.

Regards, Namik

On Mon, Jun 30, 2014 at 12:31 PM, Namik Karovic namik.karovic@gmail.com

wrote:

Hi,

I already tried setting OPENCLROOT, but it yielded the same results as any other attempt.

I get a couple of these: error: multiple definition of viennacl::linalg::double_float_conversion_program'; And a couple thousands of these: error: Cannot get section contents - auto-import exception; Resulting in this: :-1: error: CMakeFiles\ViennaCL_Benchmark.dir/objects.a(benchmark_solver.cpp.obj): bad reloc address 0x0 in section.data'

I have no idea what causes this.

Namik

On Mon, Jun 30, 2014 at 12:12 PM, PhilippeTillet < notifications@github.com> wrote:

Hi,

I think it has nothing to do with the %PATH. You probably need to set the environment variable OPENCLROOT. The CMake script will look for. $ENV{OPENCLROOT}/include/ $ENV{OPENCLROOT}/lib/x86/ $ENV{OPENCLROOT}/lib/x86_64/ With cmake handling the proper delimiters on Windows.

If the environment variable OPENCLROOT is not set, the CMake script uses ATISTREAMSDKROOT, AMDAPPSDKROOT, INTELOCLSDKROOT. Some may be missing on newer SDKs. What SDK are you using? Does it set an environment variable for the path during the installation process?

Philipe

2014-06-30 2:25 GMT+02:00 matusi143 notifications@github.com:

Namik, thank you for the update. I will wait for the next version. Do you plan on offering an interim release that will build so people can see the UI and offer feedback on the matrix market interface when that becomes available?

Phillipe, I am using Windows 8.1 so /usr won't work. Do you know how I can modify my %PATH to allow OPENCLROOT to work or is that Linux only as well?

— Reply to this email directly or view it on GitHub <

https://github.com/viennacl/viennacl-benchmark-gui/issues/2#issuecomment-47486070>

.

— Reply to this email directly or view it on GitHub < https://github.com/viennacl/viennacl-benchmark-gui/issues/2#issuecomment-47515324>

.

— Reply to this email directly or view it on GitHub https://github.com/viennacl/viennacl-benchmark-gui/issues/2#issuecomment-47521098 .

[matusi143]

Thanks guys. I'll synch things up and test this tonight. Should I be using the dev version of VIennaCL rather than 1.5.2? If so, should I be looking at June 27th image on github?

I'm using the AMD 2.9 SDK installed to its default directory. I will check out my env variables later when I get back to my test computer.

[ptillet]

Hi,

The current dev version works fine under Clang and GCC. You're more than welcome to test it with VS ; maybe it works, too ! :) However, Namik's bug may come from another previous commit. git-bisect can also help finding the origin of the error.

Philippe

2014-06-30 14:09 GMT+02:00 matusi143 notifications@github.com:

Thanks guys. I'll synch things up and test this tonight. Should I be using the dev version of VIennaCL rather than 1.5.2? If so, should I be looking at June 27th image on github?

I'm using the AMD 2.9 SDK installed to its default directory. I will check out my env variables later when I get back to my test computer.

— Reply to this email directly or view it on GitHub https://github.com/viennacl/viennacl-benchmark-gui/issues/2#issuecomment-47523941 .

[namikk]

Can you reset before my Sat Jun 28th commit and retry? I pushed some big

changes, which have not yet been tested on windows.

Philippe, thanks for the hint. I made a local temporary ViennaCL branch from the 2014-06-25 23:36:12 commit. I then manually added Karl's multiple definitions fix https://github.com/viennacl/viennacl-dev/commit/d47c8ab94b4f204573cca6fea1dd23e858e7098c. It works great now. And there's more good news. I just tested full benchmark_solver, including CG solver (ILU0 preconditioner) via ViennaCL, compressed_matrix that was causing the Heisenbug. It seems to be gone now. I'll have to do more testing in order to confirm it though.

Many thanks for the help, Namik

On Mon, Jun 30, 2014 at 2:09 PM, matusi143 notifications@github.com wrote:

Thanks guys. I'll synch things up and test this tonight. Should I be using the dev version of VIennaCL rather than 1.5.2? If so, should I be looking at June 27th image on github?

I'm using the AMD 2.9 SDK installed to its default directory. I will check out my env variables later when I get back to my test computer.

— Reply to this email directly or view it on GitHub https://github.com/viennacl/viennacl-benchmark-gui/issues/2#issuecomment-47523941 .

[matusi143]

Namik,

Much progress, however, I am now encountering the following error in CMake:

Boost version: 1.56.0 CMake Error at CMakeLists.txt:72 (find_package): By not providing "FindOpenCL.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "OpenCL", but CMake did not find one.

Could not find a package configuration file provided by "OpenCL" with any of the following names:

OpenCLConfig.cmake
opencl-config.cmake

Add the installation prefix of "OpenCL" to CMAKE_PREFIX_PATH or set "OpenCL_DIR" to a directory containing one of the above files. If "OpenCL" provides a separate development package or SDK, be sure it has been installed.

I had a ton of qt5 errors but I was able to find those files and get past them by manually entering them. For example:

C:\Qt\5.3\msvc2013_64\lib\cmake\Qt5Quick

Unfortunately, it looks like OpenCLConfig.cmake should be part of the benchmark-gui and perhaps it is not checked into the repository. Any help would be greatly appreciated.

Thanks, -Matt

[matusi143]

Phillipe,

Thank you, setting my boost_root and OPENCLROOT to the appropriate directories in the environmental variables worked well.

Trying to build the latest version of viennacl in cmake was a long process in manually finding files but ultimately worked pretty well. As the release gets closer, please let me know and I will test the process on Windows 8.1, CMake 3.0 and 2.8.11.2 with VS2013.

Thanks, -Matt

[karlrupp]

The build errors on Visual Studio with the latest tip of viennacl-dev should be fixed here: https://github.com/viennacl/viennacl-dev/commit/2582f9b253074c1efdc8f97b358cc0e434999a11 Currently there are still quite a number of warnings emitted, I'll work with Philippe on fixing these asap.

[matusi143]

Karl,

Thank you, the CMake for viennacl-dev as well as the compile with VS2013 now runs well. There are a bunch of warning as you mentioned. Thank you, as always, for the quick turnaround!

-Matt

[matusi143]

Namik,

I am still having trouble using CMake with viennacl-benchmark-gui. I will repost my message from a couple days ago for reference.

Thanks, -Matt

Boost version: 1.56.0 CMake Error at CMakeLists.txt:72 (find_package): By not providing "FindOpenCL.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "OpenCL", but CMake did not find one.

Could not find a package configuration file provided by "OpenCL" with any of the following names:

OpenCLConfig.cmake opencl-config.cmake

Add the installation prefix of "OpenCL" to CMAKE_PREFIX_PATH or set "OpenCL_DIR" to a directory containing one of the above files. If "OpenCL" provides a separate development package or SDK, be sure it has been installed.

[namikk]

Matthew,

I guess you didn't notice I updated the Readme file to better describe building with OpenCL.

First you need to make sure your CMake has the FindOpenCL module. The error you are seeing is due to CMake not having this module and thus not being able to automatically find OpenCL. To add it, get the FindOpenCL.cmake file found in viennacl/viennacl-dev/cmake/ folder and copy it to your CMake's modules folder - e.g. C:\Program Files (x86)\CMake 2.8\share\cmake-2.8\Modules. Your CMake should now be able to automatically find OpenCL libs, headers, and dlls.

Also take care that OPENCLROOT variable is set ( I guess you've done this already) and that OpenCL.dll can be found in your environment path (if it can't be found, try adding the bin folder of your OpenCL SDK to your system path).

That's all that needs to be done, as far as I know.

Best regards, Namik

On Wed, Jul 2, 2014 at 7:03 PM, Matthew Musto notifications@github.com wrote:

Namik,

I am still having trouble using CMake with viennacl-benchmark-gui. I will repost my message from a couple days ago for reference.

Thanks, -Matt

Boost version: 1.56.0 CMake Error at CMakeLists.txt:72 (find_package): By not providing "FindOpenCL.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "OpenCL", but CMake did not find one.

Could not find a package configuration file provided by "OpenCL" with any of the following names:

OpenCLConfig.cmake opencl-config.cmake

Add the installation prefix of "OpenCL" to CMAKE_PREFIX_PATH or set "OpenCL_DIR" to a directory containing one of the above files. If "OpenCL" provides a separate development package or SDK, be sure it has been installed.

—

Reply to this email directly or view it on GitHub https://github.com/viennacl/viennacl-benchmark-gui/issues/2#issuecomment-47805624 .

[karlrupp]

Thanks for looking into this, Namik. I think we can also use the same approach here as for viennacl-dev and just hold the FindOpenCL.cmake separately. I'll play with this (hopefully) tomorrow.

[matusi143]

Namik,

Thank you. I had not checked the readme file again. Moving that file allowed CMake to complete. I'm still running into some warning with CMake and ultimately the build in VS2013 didn't work perfectly but I want to spend some time with it first before bothering any of you guys with it.

Thanks again! -Matt

[matusi143]

Namik,

I mentioned I was still having issues building on VS2013 and I have been unable to easily solve it. Here is the error I am getting.

:-1: error: D8021 : invalid numeric argument '/Wno-unused-local-typedefs'

Output: 07:35:33: Starting: "C:\Qt\Tools\QtCreator\bin\jom.exe" C:\Qt\Tools\QtCreator\bin\jom.exe -f Makefile.Debug C:\Qt\5.3\msvc2013_64\bin\uic.exe ..\viennacl-benchmark-gui-master\src\ui\mainwindow.ui -o ui_mainwindow.h cl -c -nologo -Zm200 -Zc:wchar_t -FS -Wno-unused-local-typedefs -Wno-unused-parameter -Zi -MDd -GR -W3 -w34100 -w34189 -EHsc /Fddebug\ViennaCL_Benchmark.pdb -DUNICODE -DWIN32 -DWIN64 -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_OPENGL_ES_2 -DQT_OPENGL_ES_2_ANGLE -I"..\viennacl-dev-master" -I"..\boost_dev\boost_root" -I"..\Qt\5.3\msvc2013_64\include" -I"..\Qt\5.3\msvc2013_64\include\QtWidgets" -I"..\Qt\5.3\msvc2013_64\include\QtGui" -I"..\Qt\5.3\msvc2013_64\include\QtANGLE" -I"..\Qt\5.3\msvc2013_64\include\QtCore" -I"debug" -I"." -I"." -I"..\Qt\5.3\msvc201364\mkspecs\win32-msvc2013" -Fodebug\ @C:\Users\MATTH~1\AppData\Local\Temp\main.obj.10192.188.jom cl : Command line error D8021 : invalid numeric argument '/Wno-unused-local-typedefs' cl -c -nologo -Zm200 -Zc:wchar_t -FS -Wno-unused-local-typedefs -Wno-unused-parameter -Zi -MDd -GR -W3 -w34100 -w34189 -EHsc /Fddebug\ViennaCL_Benchmark.pdb -DUNICODE -DWIN32 -DWIN64 -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_OPENGL_ES_2 -DQT_OPENGL_ES_2_ANGLE -I"..\viennacl-dev-master" -I"..\boost_dev\boost_root" -I"..\Qt\5.3\msvc2013_64\include" -I"..\Qt\5.3\msvc2013_64\include\QtWidgets" -I"..\Qt\5.3\msvc2013_64\include\QtGui" -I"..\Qt\5.3\msvc2013_64\include\QtANGLE" -I"..\Qt\5.3\msvc2013_64\include\QtCore" -I"debug" -I"." -I"." -I"..\Qt\5.3\msvc201364\mkspecs\win32-msvc2013" -Fodebug\ @C:\Users\MATTH~1\AppData\Local\Temp\menulistwidget.obj.10192.188.jom cl -c -nologo -Zm200 -Zc:wchar_t -FS -Wno-unused-local-typedefs -Wno-unused-parameter -Zi -MDd -GR -W3 -w34100 -w34189 -EHsc /Fddebug\ViennaCL_Benchmark.pdb -DUNICODE -DWIN32 -DWIN64 -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_OPENGL_ES_2 -DQT_OPENGL_ES_2_ANGLE -I"..\viennacl-dev-master" -I"..\boost_dev\boost_root" -I"..\Qt\5.3\msvc2013_64\include" -I"..\Qt\5.3\msvc2013_64\include\QtWidgets" -I"..\Qt\5.3\msvc2013_64\include\QtGui" -I"..\Qt\5.3\msvc2013_64\include\QtANGLE" -I"..\Qt\5.3\msvc2013_64\include\QtCore" -I"debug" -I"." -I"." -I"..\Qt\5.3\msvc201364\mkspecs\win32-msvc2013" -Fodebug\ @C:\Users\MATTH~1\AppData\Local\Temp\qcustomplot.obj.10192.203.jom cl : Command line error D8021 : invalid numeric argument '/Wno-unused-local-typedefs' jom: C:\build-ViennaCL_Benchmark-Desktop_Qt_5_3_0_MSVC2013_64bit-Debug\Makefile.Debug [debug\menulistwidget.obj] Error 2 cl : Command line error D8021 : invalid numeric argument '/Wno-unused-local-typedefs' jom: C:\build-ViennaCL_Benchmark-Desktop_Qt_5_3_0_MSVC2013_64bit-Debug\Makefile.Debug [debug\qcustomplot.obj] Error 2 jom: C:\build-ViennaCL_Benchmark-Desktop_Qt_5_3_0_MSVC2013_64bit-Debug\Makefile.Debug [debug\main.obj] Error 2 jom: C:\build-ViennaCL_Benchmark-Desktop_Qt_5_3_0_MSVC2013_64bit-Debug\Makefile [debug] Error 2 07:35:34: The process "C:\Qt\Tools\QtCreator\bin\jom.exe" exited with code 2. Error while building/deploying project ViennaCL_Benchmark (kit: Desktop Qt 5.3.0 MSVC2013 64bit) When executing step 'Make' 07:35:34: Elapsed time: 00:06.

Commenting out:

Disable unused warnings that come from Boost and QCustomPlot

CONFIG += warn_off

QMAKE_CXXFLAGS += -Wno-unused-local-typedefs

QMAKE_CXXFLAGS += -Wno-unused-parameter

Did not make any difference. It appears you were trying to suppress that warning anyway. Any help would be greatly appreciated.

Thanks, -Matt

[namikk]

Hi Matthew,

I really can't say what is causing these errors. My guess is something's not compatible with msvc compiler. I'm using mingw and have never seen errors like these. I'm gonna try and build with msvc to see what's wrong. Will update if I make any progress.

Regards, Namik

[karlrupp]

Hey Matthey, did you use a plain CMake build? If so, try to wipe the build folder and rerun CMake. Sometimes these settings don't get wiped out of the cache correctly. I can see that the respective add_definitions()-clause is commented out for both CMake and QMake, so should not cause a problem.

[matusi143]

CMake is running well now. Still a few nits with the output still inserting gcc specific compiler flags. How best do you want me report those issues? Or rather, should I just submit a fix in the git repository for review and possible acceptance?

[karlrupp]

@matusi143 : I just promoted you to collaborator, so feel free to commit 'trivial' fixes directly. For changes which you're not confident about (maybe os-specific, compiler-specific, etc.), please commit them to a new branch and issue a pull request so that we can first check them. Thanks a lot for your contributions :-)

[matusi143]

@karlrupp : Thank you :-) I will be sure to be careful and likely submit even trivial changes to a new branch until I confident in the process.

[karlrupp]

@matusi143 : Haha, we are not working in a strict law&order style, so don't be overly hesitant. ;-)

[ptillet]

@matusi143 https://github.com/matusi143 : Yes, don't be too conservative. I personally usually only test compilation and the tests relevant to what I changed. This is not perfect as we saw recently, as blas3_prod-test-opencl can work but nmf-test-opencl can fail! Running the whole test suite after each commit is impractical, though, so I find it better to check the Dash every morning and investigate the errors...

2014-07-08 13:45 GMT+02:00 Karl Rupp notifications@github.com:

@matusi143 https://github.com/matusi143 : Haha, we are not working in a strict law&order style, so don't be overly hesitant. ;-)

— Reply to this email directly or view it on GitHub https://github.com/viennacl/viennacl-benchmark-gui/issues/2#issuecomment-48325891 .

[karlrupp]

@PhilippeTillet : We also have email notifications via the dashboard. I'll add you to that some time in the future, for now it's still a bit fragile so I don't want to throw too many false positives at you ;-)