vgvassilev wrote: > I cannot check the actual bot since it just started a new run, but in another > `projects` build it's in `clang/21/lib/sunos/liborc_rt-x86_64.a`.
Ok, that exposed a bug somewhere in the particular toolchain when we called `TC.getCompilerRT(C.getArgs(), "orc_rt");`. That means that clang does not detect that's the right path. The issue is very likely here: https://github.com/llvm/llvm-project/blob/46de3200388c300ee871f5b4941dff0d97ba9480/clang/lib/Driver/ToolChain.cpp#L682-L703 We will need to provide a special case like we do here: https://github.com/llvm/llvm-project/blob/46de3200388c300ee871f5b4941dff0d97ba9480/clang/lib/Driver/ToolChain.cpp#L717 It's late on my end -- do you mind giving this a shot? > There **must** be some way to locate runtime libs without every command that > needs that second-guessing... This is a very long conversation. The second guessing happens because of the fact that clang computes the default resource-dir relative to the binary directory. However, if you link clang as a library against a test that relative path is wrong. This is a bit of grey area when using clang as a library and in the tests we have chosen to write tests in a such a way that we don't rely on that. If we want to test the out-of-process execution in clang-repl we need to provide such path either on the test side or here. The upshot of the current approach is that it will be useful for users and deployments outside of that one single test. If you have good ideas how to make this better I am all ears... https://github.com/llvm/llvm-project/pull/175322 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
