-
Notifications
You must be signed in to change notification settings - Fork 10.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[OpenMP] Dependency on "opt" during runtimes-configure may be missing #85933
Comments
@llvm/issue-subscribers-openmp Author: Ulrich Weigand (uweigand)
The openmp-s390x-linux builder is sporadically failing with:
```
# | clang: error: no such file or directory: '/home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/./lib/libomptarget.devicertl.a'
```
when running the test. It turns out that library isn't being built due the following configure decision:
```
-- LIBOMPTARGET: Not building DeviceRTL. Missing clang: /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/bin/clang, llvm-link: /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/bin/llvm-link, opt: OPT_TOOL-NOTFOUND, or clang-offload-packager: /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/bin/clang-offload-packager
```
(note the `OPT_TOOL-NOTFOUND`).
And even in successful builds, I sometimes see the line:
after
So it looks like there needs to be a dependency on
and this
But when only some runtimes components are enabled,
(Note that Should CC @jhuber6 @petrhosek |
I really hate the handling here, unfortunately it's a little difficult to set up the library in the way we need it without fishing a few of these tools out of the build directory. I think in the future I should be able to rewrite a lot of this, but for now does it work if you force the |
This patch seems to work for me:
|
Actually, I take it back; that seems to have been just happenstance. Looks like I confused LLVM_RUNTIME_TARGETS with LLVM_ENABLE_RUNTIMES. Need to look into this some more. |
Now I see. While executing this block of code:
nothing ever happens because Do we even need that check here? We might as well add those dependencies always ... This patch does fix the problem for me:
(The previous patch is probably also needed in case people use a non-default LLVM_RUNTIME_TARGETS ...) |
That seems correct, that probably just wasn't thought through correctly when written and moving to runtimes. If you make a PR for that I'll approve it. |
When building the OpenMP runtime with libomptarget support, the runtimes configure step needs to have a dependency on various tools, in particular opt, so that cmake configure checks yield the correct results. This did not work correctly, as the dependencies were only added if the OPENMP_ENABLE_LIBOMPTARGET was set - but that variable is only set by the openmp/CMakeLists.txt file, which isn't even parsed during the initial cmake run (in fact, it is only parsed when executing the runtimes configure step itself, but then it is too late). Fixed by just adding those dependencies always. In addition, the list of dependencies collected in ${extra_deps}, including those required for OpenMP, was only actually used when configuring runtimes for the default set of targets - when the user specifies a non-default LLVM_RUNTIME_TARGETS, those extra dependencies were ignored (with the exception of ${hdrgen_deps}). Fixed by passing the full ${extra_deps} in this case as well. Fixes: llvm#85933
When building the OpenMP runtime with libomptarget support, the runtimes configure step needs to have a dependency on various tools, in particular opt, so that cmake configure checks yield the correct results. This did not work correctly, as the dependencies were only added if the OPENMP_ENABLE_LIBOMPTARGET was set - but that variable is only set by the openmp/CMakeLists.txt file, which isn't even parsed during the initial cmake run (in fact, it is only parsed when executing the runtimes configure step itself, but then it is too late). Fixed by just adding those dependencies always. In addition, the list of dependencies collected in ${extra_deps}, including those required for OpenMP, was only actually used when configuring runtimes for the default set of targets - when the user specifies a non-default LLVM_RUNTIME_TARGETS, those extra dependencies were ignored (with the exception of ${hdrgen_deps}). Fixed by passing the full ${extra_deps} in this case as well. Fixes: #85933
When building the OpenMP runtime with libomptarget support, the runtimes configure step needs to have a dependency on various tools, in particular opt, so that cmake configure checks yield the correct results. This did not work correctly, as the dependencies were only added if the OPENMP_ENABLE_LIBOMPTARGET was set - but that variable is only set by the openmp/CMakeLists.txt file, which isn't even parsed during the initial cmake run (in fact, it is only parsed when executing the runtimes configure step itself, but then it is too late). Fixed by just adding those dependencies always. In addition, the list of dependencies collected in ${extra_deps}, including those required for OpenMP, was only actually used when configuring runtimes for the default set of targets - when the user specifies a non-default LLVM_RUNTIME_TARGETS, those extra dependencies were ignored (with the exception of ${hdrgen_deps}). Fixed by passing the full ${extra_deps} in this case as well. Fixes: llvm#85933
The openmp-s390x-linux builder is sporadically failing with:
when running the test. It turns out that library isn't being built due the following configure decision:
(note the
OPT_TOOL-NOTFOUND
).And even in successful builds, I sometimes see the line:
after
So it looks like there needs to be a dependency on
opt
for theruntimes-configure
target, but this may be missing. Looking at thellvm/runtimes/CMakeLists.txt
file, I see this block:and this
extra_deps
variable is used when configuring the default runtimes target:But when only some runtimes components are enabled,
extra_deps
doesn't appear to be used:(Note that
hdrgen_deps
is also present inextra_deps
, but the latter may include many more dependencies.)Should
extra_deps
be used here as well?CC @jhuber6 @petrhosek
The text was updated successfully, but these errors were encountered: