I think the issue is that you don't have the conda environment activated. Activating the conda environment sets the SDKROOT env variable so that clang can find the macOS SDK.
I maintain the pocl conda package with some other maintainers. You can find our build scripts at https://github.com/conda-forge/pocl-feedstock/blob/main/recipe/build.sh Isuru On Fri, May 20, 2022 at 9:38 AM Noah Reddell <[email protected]> wrote: > Hi, > I upgraded to an M1 Pro Mac and found that MacOS's built-in OpenCL > implementation no longer supports the CPU device. The GPU is > supported -- for now at least, but doesn't do fp64. > I'm very motivated to have a local OpenCL platform on my Mac that > supports CPU device. This is by far the most productive way for me to > first debug and develop kernels versus GPU-based debugging or on > remote systems. So I return to POCL but for the first time trying to > use it on a Mac. I'm having struggles. (latest releases MacOS > 12.3.1, XCode 13.4) > > My problems trying to build and run the latest POCL are more complex, > so I'll first mention a problem trying to use POCL acquired with the > Conda package manager this week. I can build and run a simple > hello-world program with one kernel and it computes the right answers > using POCL. > OpenCL Devices Detected: > Platform: Portable Computing Language > Type: CPU, Name: pthread > > > Unfortunately, when I run my large computational science application, > I get a runtime error shortly after the first call to > clEnqueueNDRangeKernel(). The function returns CL_SUCCESS, another > thread raises SIGABRT, I assume after the following output: > > ld: dynamic main executables must link with libSystem.dylib for > architecture arm64 > error: linker command failed with exit code 1 (use -v to see invocation) > Final linking of kernel physical_initial_condition_evaluation failed. > > Since my hello-world app works, yet the app I care about doesn't, my > leading suspicion so far is some confusion about which clang / llvm is > getting utilized. I've tried to be careful about what PATH is set and > I'm not setting DYLD_LIBRARY_PATH in any way. > I'd love to pass "-v" to the POCL link as suggested, but I'm not sure > how to do that. > The main application *is* linked with -lSystem so that error message > is probably referring to the POCL kernel build. > It looks like POCL_MSG_PRINT_LLVM could be helpful, but I think that > is only set when POCL is built, and I'm not able to build. > > Ok, so any suggestions about the above problem would be appreciated! > > > Sometime I'd really like to be able to build POCL myself. > > I can tell that some special steps are needed to get the latest POCL > to build for MacOS. Who is maintaining that Conda package? Are the > build steps available? > > Lesser question stemming from my failed attempts to build POCL from > source: > Question: What is the difference between the "basic" device and > "pthread" device? I'm not finding documentation for either host > devices. > One reason I ask is that I found problems building "pthread" due to > Apple's pthread.h not including pthread_barrier support. Looks > like two lines in CMakeLists.txt under if(ENABLE_HOST_CPU_DEVICES) > could be modified to turn off the pthreads device. I also had > success naively providing implementations of the missing functions in > file pthread_scheduler.c > > > > Warm regards, > > Noah > > > _______________________________________________ > pocl-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/pocl-devel >
_______________________________________________ pocl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pocl-devel
