This is an archive of the discontinued LLVM Phabricator instance.

[OpenMP] libomptarget: Disable on MacOS X

Authored by grokos on Mar 16 2017, 1:50 PM.



Compiling on MacOS X fails due to the darwin liner not supporting the --version-script option.

Currently, device plugins (cuda, genereic-elf-64) are only supported on Linux anyway, so there is no point in trying to compile libomptarget on other systems.

Thanks to Jack Howarth for reporting this issue.

Bugzilla no 32309.

Diff Detail


Event Timeline

grokos created this revision.Mar 16 2017, 1:50 PM
Hahnfeld edited edge metadata.Mar 17 2017, 12:09 AM

Ideally, we should check if the linker supports --version-script, but currently this yields no benefit.


Should we do this the other way around and say CMAKE_SYSTEM_NAME MATCHES "Linux"?

grokos added inline comments.Mar 17 2017, 11:42 AM

Technically, the plugins' CMakeLists.txt's require that the build system is Linux, however there is no reason I'm aware of why they cannot be built on any Unix system, as long as it supports the ELF executable format (e.g. FreeBSD). So maybe the best choice is to leave the condition above as-is (!win32 && !darwin) and change the plugins' CMakeLists to support general Unices. Any thoughts?

Hahnfeld requested changes to this revision.Mar 20 2017, 12:09 AM
Hahnfeld added inline comments.

Darwin is also Unix-like. If I see that correctly, only the linker doesn't support --version-script which is only needed for public / private symbols. In that case, it would be best to have a config-ix.cmake check and only add the flag in libomptarget/CMakeLists.txt and libomptarget/plugins/CMakeLists.txt if supported by the building environment.

This revision now requires changes to proceed.Mar 20 2017, 12:09 AM
grokos added inline comments.Mar 20 2017, 5:10 PM

Darwin is Unix-like, but it does NOT support ELF, it uses Mach-O, so the plugins will not work. E.g. headers elf.h and libelf.h do not exist on MacOS X.

Besides, if I just omit the version script there are more compilation errors related to undefined references to functions from the host runtime. This is the output I get:

[ 94%] Linking C shared library libomp.dylib
[ 94%] Built target omp
Scanning dependencies of target omptarget
[ 97%] Building CXX object libomptarget/CMakeFiles/omptarget.dir/src/omptarget.cpp.o
[100%] Linking CXX shared library libomptarget.dylib
Undefined symbols for architecture x86_64:
  "___kmpc_omp_taskwait", referenced from:
      ___tgt_target_data_begin_nowait in omptarget.cpp.o
      ___tgt_target_data_end_nowait in omptarget.cpp.o
      ___tgt_target_data_update_nowait in omptarget.cpp.o
      ___tgt_target_nowait in omptarget.cpp.o
      ___tgt_target_teams_nowait in omptarget.cpp.o
  "_omp_get_default_device", referenced from:
      ___tgt_target_data_begin in omptarget.cpp.o
      ___tgt_target_data_end in omptarget.cpp.o
      ___tgt_target_data_update in omptarget.cpp.o
      ___tgt_target in omptarget.cpp.o
      ___tgt_target_teams in omptarget.cpp.o
      ___kmpc_push_target_tripcount in omptarget.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [libomptarget/libomptarget.dylib] Error 1
make[1]: *** [libomptarget/CMakeFiles/omptarget.dir/all] Error 2
make: *** [all] Error 2

I guess this is due to the way MacOS handles weak linkage, but I'm not an expert here.

Hahnfeld accepted this revision.Mar 21 2017, 12:18 AM

I thought the library would just compile fine and that the CUDA plugin should work without ELF support - turns out both don't because the CUDA plugin uses ELF to verify the binary header. This could certainly be solved differently but that's future work if someone is interested.

This revision is now accepted and ready to land.Mar 21 2017, 12:18 AM
This revision was automatically updated to reflect the committed changes.