You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am currently facing some troubles while getting the SYCL compiler to run on a cluster equipped with Alveo U200 FPGAs. The cluster is running CentOS; unfortunately all default system tools are so ancient that they'd actually belong into a museum. The cluster's module system allows me to load more recent compilers and libraries, so I was able to compile the SYCL compiler (with some changes to sycl-clang's include files and overriding system include directories).
Running it opens up another can of worms since the Xilinx tools don't seem to play nice with the module system. xocc doesn't even consider using the compiler defined by the environment variables, instead it always wants to call /usr/bin/g++ through the xcpp wrapper. It also doesn't use the include directories I gave to the sycl-clang frontend, which causes the called g++ to fail because it doesn't find the standard library includes.
So far I tried adjusting the environment variables for the compiler (CPATH, CPLUS_INCLUDE_PATH, LD_LIBRARY_PATH) as well as copying xcpp to a local PATH and modifying the call to gcc, all to no avail or even more weird problems with header files and libraries.
is there some obvious way I'm missing that doesn't require any system-wide changes? I can't write to the SDAccel installation directory or any other system directory since I don't have root privileges.
The text was updated successfully, but these errors were encountered:
Yes, this is complex... :-(
But do you need to use such a host compiler if you are not using software or hardware emulation with xocc?
If you want to use hardware or software emulation, you might just use a modern machine instead of a cluster node with FPGA access.
Could it be possible to actually just compile on another machine and just have XRT to load the program on the cluster? Perhaps you can link a lot of stuff statically too...
Could it be possible to actually just compile on another machine and just have XRT to load the program on the cluster?
That worked surprisingly well, despite a (slight) version mismatch between my local machine and the cluster's modules. I can successfully execute the examples on FPGA hardware this way.
But do you need to use such a host compiler if you are not using software or hardware emulation with xocc?
It would be nice to be able to launch build jobs over night on the cluster, especially for the hardware synthesizing. My co-workers work directly on the cluster, so passing build scripts around would also be superior to everyone setting up the toolchain on their local OS (which might not be Ubuntu 19.04)...
An easy way is to have everything modern on the cluster.
With modern software and languages, less global warming at the end of the day because of a more efficient use of hardware and brains. :-)
This is probably possible to spend a lot of IT time to install all the modern dependencies on top of an obsolete OS... No easy answer...
A container approach providing all the modern SYCL compilation stack could be a good compromise.
I am currently facing some troubles while getting the SYCL compiler to run on a cluster equipped with Alveo U200 FPGAs. The cluster is running CentOS; unfortunately all default system tools are so ancient that they'd actually belong into a museum. The cluster's module system allows me to load more recent compilers and libraries, so I was able to compile the SYCL compiler (with some changes to sycl-clang's include files and overriding system include directories).
Running it opens up another can of worms since the Xilinx tools don't seem to play nice with the module system.
xocc
doesn't even consider using the compiler defined by the environment variables, instead it always wants to call/usr/bin/g++
through thexcpp
wrapper. It also doesn't use the include directories I gave to the sycl-clang frontend, which causes the called g++ to fail because it doesn't find the standard library includes.So far I tried adjusting the environment variables for the compiler (CPATH, CPLUS_INCLUDE_PATH, LD_LIBRARY_PATH) as well as copying xcpp to a local PATH and modifying the call to gcc, all to no avail or even more weird problems with header files and libraries.
is there some obvious way I'm missing that doesn't require any system-wide changes? I can't write to the SDAccel installation directory or any other system directory since I don't have root privileges.
The text was updated successfully, but these errors were encountered: