I find no difference exporting SDKROOT at build time, run time, or both. 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 phase_initial_condition_evaluation failed.
(base) noah@Spitzer ~ % which xcrun /usr/bin/xcrun (base) noah@Spitzer ~ % xcrun --show-sdk-path /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk When are you supposing SDKROOT in the environment affects behavior? I tried to use dtruss to catch whatever system calls are happening under clEnqueueNDRangeKernel() but that system utility isn't catching anything. ...MacOS security I think. -Noah On Fri, May 20, 2022 at 9:14 AM Isuru Fernando <[email protected]> wrote: > > Ah, that makes sense now. Can you try doing the following? > > export SDKROOT=$(xcrun --show-sdk-path) > > (Note that the clang you are using and the one from conda that pocl is using > are two different things) > > Isuru > > On Fri, May 20, 2022 at 10:41 AM Noah Reddell <[email protected]> > wrote: >> >> Hi Isuru, >> Thank you for maintaining the conda package and the suggestion. >> >> It is true I don't have the conda environment activated when building >> / running my large app. I installed conda for the sole purpose of >> POCL and generally use homebrew for similar needs. I'm not seeing >> any difference in build/run of hello-opencl whether I have conda >> activated or not. SDKROOT is not set either way. >> >> Starting with a fresh shell: >> ---------------------------------------------- >> Last login: Wed May 18 22:48:50 on ttys005 >> noah@Spitzer ~ % clang -g -L/Users/noah/miniforge3/lib/ >> -Wl,-rpath,/Users/noah/miniforge3/lib/ -lOpenCL >> /Users/noah/Downloads/hello_opencl.c >> noah@Spitzer ~ % ./a.out >> Num Platforms: 1 >> platform[0] name: Portable Computing Language >> platform[0] Num Devices: 1 >> device[0] name: pthread >> function definition may only have a distinct !dbg attachment >> i64 (i32)* @_Z13get_global_idj >> Computed '1024/1024' correct values! >> noah@Spitzer ~ % echo $SDKROOT >> >> noah@Spitzer ~ % source /Users/noah/miniforge3/etc/profile.d/conda.sh >> noah@Spitzer ~ % conda activate >> (base) noah@Spitzer ~ % echo $SDKROOT >> >> (base) noah@Spitzer ~ % clang -g -L/Users/noah/miniforge3/lib/ >> -Wl,-rpath,/Users/noah/miniforge3/lib/ -lOpenCL >> /Users/noah/Downloads/hello_opencl.c >> (base) noah@Spitzer ~ % ./a.out >> Num Platforms: 1 >> platform[0] name: Portable Computing Language >> platform[0] Num Devices: 1 >> device[0] name: pthread >> function definition may only have a distinct !dbg attachment >> i64 (i32)* @_Z13get_global_idj >> Computed '1024/1024' correct values! >> >> (base) noah@Spitzer ~ % which clang >> /usr/bin/clang >> ---------------------------------------------- >> >> >> I'll check out your build.sh recipe. At first glance, it is not >> clear to me how you're dealing with the MacOS pthread not having >> pthread_barrier_t and related functions. When I tried to build POCL >> last week, those pthread parts are needed. >> >> Cheers, >> -Noah >> >> >> On Fri, May 20, 2022 at 7:51 AM Isuru Fernando <[email protected]> wrote: >> > >> > 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 >> >> >> _______________________________________________ >> 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 _______________________________________________ pocl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pocl-devel
