Hello.
I’m trying to run computecpp-sdk samples on Manjaro Linux.
The installation and compilation processes went smoothly (with the exception of the “UNTESTED - Untested OS” message printed in the output the “computecpp_info” script). However when I try to run any of the samples I get the following error:
simple-vector-add: /build/psgswbuild/nightly/19.4/64/l64/p4/acl/llvm/include/llvm/Support/CommandLine.h:813: void llvm::cl::parser<DataType>::addLiteralOption(llvm::StringRef, const DT&, llvm::StringRef) [with DT = llvm::FunctionPass* (*)(); DataType = llvm::FunctionPass* (*)()]: Assertion `findOption(Name) == Values.size() && "Option already exists!"' failed.
[1] 9386 abort (core dumped) ./simple-vector-add
Does anyone know what may be going on? Do you think it is simply because I’m trying to run SYCL on an Arch based system (officially not supported by ComputeCpp)?
Hi @ducbueno,
I doubt that it’s because you’re running Manjaro, I don’t use Arch at work but I have used it on my own machine at home with ComputeCpp a couple of times, I don’t believe the situation has changed.
What OpenCl are you using to run the samples? Is it Beignet? If it is, on this pure shot in the dark, I don’t believe that’s going to work, as Intel stopped working on it some time ago. However, Intel’s CPU implementation should work well, as should their newer open-source driver (Intel Compute Runtime on GitHub).
If you’re already running one of those and still getting those errors, please let me know and we can investigate further.
Duncan.
ETA: you could also attach the output of computecpp_info, that will show us what platforms and devices are available on your system which should help us too.
Hello @duncan.
Thank you for your quick response and sorry for taking so long to reply back to you.
I solved the problem by reinstalling the LLVM and CLANG related packages from source.
However, now I’m facing another issue. I’m trying to build the makefile_basic application available on the computecpp-sdk and I’m getting errors on the linking phase:
g++ app.o -L/mnt/Tools/ComputeCpp-CE-1.3.0-x86_64/lib -o app
/usr/bin/ld: app.o: in function main::{lambda(cl::sycl::handler&)#1}::operator()(cl::sycl::handler&) const::{lambda()#1}::~handler()': app.cpp:(.text+0x7a): undefined reference to cl::sycl::stream::~stream()’
I think this may be due to the fact that I’m trying to run the ComputeCpp-CE from Ubuntu 16.04 in Manjaro. I went to the download page of ComputeCpp-CE and tried to download the generic linux package, however I keep getting the message “Error, no valid license found. Please contact support@codeplay.com”.
Do you (or anyone else) have any idea how can I fix this?
Thanks again
Hi @ducbueno,
It’s not really likely to be that issue. We’ve updated our package naming to reflect that we’re relatively distribution-independent now, which might have been a point of confusion before.
I’ve not updated the Makefile sample for a while, though I suppose it shouldn’t have broken. There are two main things: firstly, since you’re on a rolling-release distribution, which version of GCC do you have? Secondly, the main way we support using ComputeCpp is through CMake - have you tried building the samples in the SDK as described in the README? Would be interesting to know if that works instead.
Thanks,
Duncan.
Hello again @duncan.
The version of my GCC is 9.3.0.
I was able to build the samples with CMake, everything is working fine.
The reason I started messing around with the Makefile sample was to be able to determine what is the minimal build set-up needed to compile a SYCL + ComputeCpp application. This is interesting to me because I intend to integrate SYCL into a bigger project, and CMake is still a little bit cryptic to me (and also looks a little bloated…). If there is a minimal CMake configuration somewhere it would also be helpful.
Thanks!
Hi,
so we have an integration guide on the website which covers the steps required to run a ComputeCpp program. The makefile sample basically covers these steps but I would personally find it hard to scale the makefile solution to a larger project, while our CMake configuration has mostly had its bugs worked out. You can find a basic CMake example in the same location as the makefile sample, but the samples of the SDK are just as good an example IMO (samples/CMakeLists.txt).
The reason I asked for your compiler version is that there are some possible incompatibilities with some recent versions of GCC that we’re looking into. Would you be able to try running the samples? (You can run ctest in the build directory to run them all.) I’m worried that there will be at least one crash at runtime.
The samples seem to be running fine (I didn’t try to run all of them though).
I was able to write a minimal Makefile for compiling simple SYCL codes. However a I wasn’t able to get entirely rid of CMake, I couldn’t get the linking step to work without it. I had to add the following line to complete the build:
/usr/bin/cmake -E cmake_link_script link.txt
The content of link.txt is a compiler command, but if I try to write this command directly in the Makefile the build doesn’t fails but the executable is not created. Do you know why this is the case?
That will just run the linker with some system-specific flags that CMake works out. I don’t know what they would be. I wouldn’t have expected any particularly special flags be required to link our applications successfully. Put another way, I’m not really sure why the sample makefile on the SDK isn’t working either - I would expect it to work just fine.
If you were using ninja to build when you tried with CMake, you can use ninja -v to show the compile commands. Those commands can be executed directly and include exactly what the linker step is doing. I can’t remember how you do it using the Makefile generator, it’s been a while since I used Make at all.
Thanks a lot @duncan!
The ninja tip solved it for me.
My minimal makefile is now working!
Would you be able to tell us what is missing? As I say, my expectation is that this should “just work”.