twister failing locally - fails to link native_posix w/lld #32237
Comments
|
Can you see which version of The docker image we use in CI is based on ubuntu 18.04.5: |
(which is apparently a lie :-) ) If Zephyr requires GNU ld in particular, perhaps it could explicitly use or specify |
galak
changed the title
|
Yep, turns out that I have a short-term workaround of "setting ld to bfd before running Zephyr tests". Longer-term, can those tests please explicitly use ld.bfd if that's what they require? There are a few other seemingly-unrelated failures still. In particular: 2 flaky tests (reran and they passed):
And a few deterministic failures (or seemingly so), in seemingly two buckets: Bucket A:
Bucket B:
Both of these buckets look like path issues. Is there additional setup I need to do beyond what I mentioned at the start? If so, what, and if so, can that please be documented better? Also, should I make separate tickets for these, or reuse this one? |
We'd need a survey of common linux distro and if the majority support ld.bfd. Or possible try ld.bfd and fall back on ld. |
QEMU is know to have issues when run under load w/twister. |
Did you do a |
Hmm, it feels like there is something else with your setup. We do nightly builds of Zephyr and aren't seeing any similar issues. How many tests are failing? can you report the specific summary here. For example for the |
Hm. I, for one, would prefer to know I was running in an unsupported configuration up front, rather than failures later.
Hm. I can reproduce this from "scratch" with the steps at the start. That is, start with a shell in an empty folder, then do:
...which likely means that something in the above is subtly incorrect. (Or blatantly incorrect and I'm just missing something.)
Hm. Is this QEMU itself? Or just exposing race conditions in Zephyr that are more prominent under system load?
I do, but not in that directory (note the directory path ends up outside the repo!) |
You're the first person I'm aware of to run into this issue. As I mentioned, I'm guessing the majority of distro installs probably still default to GNU tools. We check version of other tools, so a version check could be added to catch such an issue.
So I think the about is subtly incorrect. As you did a
Its believed to be an issue w/QEMU itself.
Sure, just confused by the specific error as its saying no such file or dir. |
Yep, that's exactly the case. I'll retry with |
It's a little unfortunate, indeed. Linux has all of the infrastructure to have system default tools with people changing around for different implementations, but there's now too much software that assumes that e.g.
Oh interesting. Is there an upstream bug report for this? |
|
Hm. With I usually have a folder structure that's essentially: etc. This makes it (relatively) straightforward to do e.g. mass fetches of repositories and avoids repos in deeply nested folders (which can be a problem in some cases). Is there no way to do this with zephyr? For now I suppose I can make a folder |
@mbolivar-nordic is probably the best person to answer this. |
Take a look at #14173 |
|
@galak - yep, rerunning with the workarounds from this thread and I only get a couple of QEMU timeouts/unexpected EOF. Good catch. And then rerunning with --only-failed Unfortunately, this one failed the same way 3/4 runs on my box. Not the end of the world, but unfortunate. |
You need to create a west workspace. Details in https://docs.zephyrproject.org/latest/guides/west/basics.html and related pages. |
I was looking at your logs and though that your For now, moving your |
|
FYI @jharris-intel, GitHub/CI will run |
well, expecting We still have some work to do before linker scripts are updated to support lld, but it is part of our plans. zephyr/cmake/toolchain/llvm/generic.cmake Line 12 in 5396350 Instead of trying to detect if users has In this case, users has the ability of telling CMake (gcc) to actually use or when using this will tell the build system to specifically use We could try to make documentation clearer on the fact that Zephyr cannot link using |
FYI in terms of helping with documentation (and hopefully making so that the next person is less confused than I was): I had seen that but had assumed that that was just for the purposes of setting up the mentioned cmake and pip stuff, not something that had to be done for every local repo copy.
Good to know...
Sure. It's more |
I see your point. |
this is already moving forward, see 265532b and then... |
|
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time. |
Fixes: zephyrproject-rtos#32237 When building for native_posix, then host tools are used. This means that gcc will link using `/usr/bin/ld` per default. If ld points to lld, then linking will fail. This commit will first look for ld.bfd, and if found then use -fuse-ld=bfd for linking. If ld.bfd is not found, then ld is used as fallback as that will be assumed to be the best working candidate. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #32237 When building for native_posix, then host tools are used. This means that gcc will link using `/usr/bin/ld` per default. If ld points to lld, then linking will fail. This commit will first look for ld.bfd, and if found then use -fuse-ld=bfd for linking. If ld.bfd is not found, then ld is used as fallback as that will be assumed to be the best working candidate. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Describe the bug
While following the contribution guide to create a PR for this comment, I realized that
twisteris failing on my local dev setup.To Reproduce
Steps to reproduce the behavior:
These steps are subtly incorrect, see below comments for details. Please do not use them as-is.
git clone https://github.com/zephyrproject-rtos/zephyr.gitcd zephyrwest initwest update./scripts/twister(as an aside, is there a way to get twister to exit after the first failing test? I can't seem to find an option for it.)Expected behavior
Testing that is documented as "please run [...] locally before submitting your pull request to GitHub." passes on trunk.
Impact
I have to guess as to if my PR changes actually break code or not, which may cause CI failures.
As per the documentation, "We highly recommend you run these tests locally to avoid any CI failures."
Logs and console output
Similar failures appear on seemingly all posix tests. (And a few others, but this is the main commonality I noted.)
Also see the attached twister.zip (zipped because it's a rather giant log file).
Overall:
Environment (please complete the following information):
Additional context
I see the DTS warning in the above; I don't think it is related (The log message does say "Optional", but famous last words?). Unfortunately, 1.4.5. is the latest version available in Ubuntu 18.04 LTS.
I'm probably just missing something obvious here. E.g. I'm using a different default
ldversion or something that the tests aren't compatible with but don't override.The text was updated successfully, but these errors were encountered: