[llvm-dev] Should the compiler-rt builtins be configured with CMAKE_TRY_COMPILE_TARGET_TYPE?

Martin Storsjö via llvm-dev llvm-dev at lists.llvm.org
Tue Mar 16 03:46:17 PDT 2021


Hi,

On Mon, 15 Mar 2021, Petr Hosek wrote:

> I've been thinking about this a bit more and doing some experiments. I'm
> no longer sure if setting CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY is
> the best solution.

Yes, it's a bit problematic in some cases too... But for passing the 
initial CMake compiler sanity check, it's either that, or passing 
CMAKE_CXX_COMPILER_WORKS.

> While it could simplify checks in projects that only ever produce static 
> libraries like builtins or crt, using it more broadly might be a problem 
> because it breaks checks like check_function_exists and 
> check_library_exists.

Yeah it can't be used straight as-is in other projects

> The idea I'm considering would be to instead roll out our own checks. The
> way checks like check_function_exists and check_library_exists work is that
> CMake generates a little snippet which it then tries to compile. For example
> when checking if dlopen in libdl exists, CMake would generate:
> 
> char dlopen(void);
> int main(int ac, char* av[]) {
>   dlopen();
> }
> 
> It'd then try to compile this file with -ldl and see if the command succeeds
> or fails. The problem with this snippet is that it implicitly uses libc and
> other libraries like crt or builtins, which in the case of the runtimes
> build, are libraries we're going to build introducing a cycle. The
> alternative I came up with would be to generate a custom snippet that looks
> like this:
> 
> char dlopen(void);
> void _start() {
>   dlopen();
> }
> 
> When invoking the compiler, we would additionally pass -nostdlib. That way,
> we would still check if libdl is available without any implicit
> dependencies. The only downside to this approach I can see is that we would
> need to maintain our own set of checks, but since we could rely on CMake's
> try_compile to do most of the heavy lifting, I don't think it'd be too much
> of a maintenance overhead.

That sounds workable to me (at least on first thought, without trying it 
out), but it'd require a bit of platform specifics, as the entry point 
function name differs a bit between platforms (on Windows, it's 
"mainCRTStartup", not "_start").

// Martin


More information about the llvm-dev mailing list