[BOLT] Fix runtime osx cross-compile build

[yota9]

Summary

Place include elf.h under !apple condition

[Amir]

CMAKE_SYSTEM_NAME is the compilation target, so it makes sense to use it instead of compiler id. We may need to add a Darwin cross-compilation target for build testing to prevent bitrot.

cc @alexander-shaposhnikov

[yota9]

bolt/runtime/CMakeLists.txt

40

Probably the target line could be removed now, how do you think @Amir @alexander-shaposhnikov ?

[alexander-shaposhnikov]

bolt/runtime/CMakeLists.txt

33

unless I'm missing something this appears to be incorrect.
Basically we used to build the osx runtime library regardless of the host platform
(clang works as a cross compiler).

[alexander-shaposhnikov]

bolt/runtime/CMakeLists.txt

33

@Amir - the runtime is not linked into BOLT, instead, it's used for creating the final output, thus the target for which we are building the project is not directly related to the target platforms supported by the tool itself.

[yota9]

bolt/runtime/CMakeLists.txt

33

The thing is that the clang may not support this target. I'm building it in arm linux env and it fails expectedly

[Amir]

bolt/runtime/CMakeLists.txt

33

@alexander-shaposhnikov
Thanks for clarifying. My mistake.

@yota9
Are you using custom-built clang? IIUC clang is supposed to be a cross-compiler out of the box. As a workaround, we can group rt_instr targets similar to LLVM_ENABLE_TARGETS and select them at configuration time.

[yota9]

bolt/runtime/CMakeLists.txt

33

You are right, this is my fault. Let me update the patch

[yota9]

Fix header include

[yota9]

@Amir The problem was not with the compiler, but with the elf dependency on darwin build. I'm not quite sure that we need config.h now, but it is definitely OK to put it under !apple condition.

[Amir]

What again was the problem? I didn't have compilation issues when building in aarch64 docker (emulation mode).

[yota9]

@Amir Do you use clang as CC/CXX for building BOLT? Also don't forget that currently the build for aarch64 is disabled in cmake.

/usr/bin/clang++   -I. -O3 -DNDEBUG   -target x86_64-apple-darwin19.6.0 -ffreestanding -fno-exceptions -fno-rtti -fno-stack-protector -std=c++11 -MD -MT CMakeFiles/bolt_rt_instr_osx.dir/instr.cpp.o -MF CMakeFiles/bolt_rt_instr_osx.dir/instr.cpp.o.d -o CMakeFiles/bolt_rt_instr_osx.dir/instr.cpp.o -c /home/yota9/src/llvm/bolt/runtime/instr.cpp
In file included from /home/yota9/src/llvm/bolt/runtime/instr.cpp:44:
In file included from /home/yota9/src/llvm/bolt/runtime/common.h:13:
In file included from /usr/include/elf.h:22:
/usr/include/features.h:461:12: fatal error: 'sys/cdefs.h' file not found
#  include <sys/cdefs.h>

It does not look as an ARM problem to me. The thing is that HAVE_ELF_H is defined in config.h file since it is defining for the host compiler, but used for cross compile tool. I assume the osx instrumentation is working because in instr.cpp we have:

#if defined(HAVE_ELF_H) and !defined(__APPLE__)

And the second one is not true for the cross tool. But anyway we should not try include elf.h for non-linux target.

[Amir]

In D119038#3303006, @yota9 wrote:

@Amir Do you use clang as CC/CXX for building BOLT? Also don't forget that currently the build for aarch64 is disabled in cmake.

/usr/bin/clang++   -I. -O3 -DNDEBUG   -target x86_64-apple-darwin19.6.0 -ffreestanding -fno-exceptions -fno-rtti -fno-stack-protector -std=c++11 -MD -MT CMakeFiles/bolt_rt_instr_osx.dir/instr.cpp.o -MF CMakeFiles/bolt_rt_instr_osx.dir/instr.cpp.o.d -o CMakeFiles/bolt_rt_instr_osx.dir/instr.cpp.o -c /home/yota9/src/llvm/bolt/runtime/instr.cpp
In file included from /home/yota9/src/llvm/bolt/runtime/instr.cpp:44:
In file included from /home/yota9/src/llvm/bolt/runtime/common.h:13:
In file included from /usr/include/elf.h:22:
/usr/include/features.h:461:12: fatal error: 'sys/cdefs.h' file not found
#  include <sys/cdefs.h>

It does not look as an ARM problem to me. The thing is that HAVE_ELF_H is defined in config.h file since it is defining for the host compiler, but used for cross compile tool. I assume the osx instrumentation is working because in instr.cpp we have:

#if defined(HAVE_ELF_H) and !defined(__APPLE__)

And the second one is not true for the cross tool. But anyway we should not try include elf.h for non-linux target.

Ah, yes, I've seen this issue but worked around it. Thanks for properly fixing it! This reason is sufficient:

we should not try include elf.h for non-linux target.

bolt/runtime/CMakeLists.txt

 target_compile_options(bolt_rt_instr PRIVATE -ffreestanding -fno-exceptions -fno-rtti -fno-stack-protector -fPIE)
 target_include_directories(bolt_rt_instr PRIVATE ${CMAKE_CURRENT_BINARY_DIR})
 target_compile_options(bolt_rt_hugify PRIVATE -ffreestanding -fno-exceptions -fno-rtti -fno-stack-protector)
 target_include_directories(bolt_rt_hugify PRIVATE ${CMAKE_CURRENT_BINARY_DIR})
 
 install(TARGETS bolt_rt_instr DESTINATION lib)
 install(TARGETS bolt_rt_hugify DESTINATION lib)
 
-if (CMAKE_CXX_COMPILER_ID MATCHES ".*Clang.*")
+if(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
   add_library(bolt_rt_instr_osx STATIC
     instr.cpp
     ${CMAKE_CURRENT_BINARY_DIR}/config.h
   )
   target_include_directories(bolt_rt_instr_osx PRIVATE ${CMAKE_CURRENT_BINARY_DIR})
   target_compile_options(bolt_rt_instr_osx PRIVATE
     -target x86_64-apple-darwin19.6.0
     -ffreestanding
     -fno-exceptions
     -fno-rtti
     -fno-stack-protector)
   install(TARGETS bolt_rt_instr_osx DESTINATION lib)
 endif()