Change:
} /// Adds a list of lookup paths to `cmd`'s dynamic library lookup path. <ins> /// If The dylib_path_par is already set for this cmd, the old value will be overwritten! </ins> pub fn add_dylib_path(path: Vec<PathBuf>, cmd: &mut Command) { let mut list = dylib_path(); for path in path {

Discussion:
I have in case that makes a difference.
Miri also runs into this when doing (which used to work)
:
I believe this may have been resolved some time between the issue being created and now. When i tried to reproduce it locally () the error index tests were able to start and run just fine. The tests failed with "error[E0658]: const generics are unstable" because some snippets use instead of the recently stabilised , but that doesn't have anything to do with being unable to load shared libraries. Similarly I was able to run without an issue. and are you still able to reproduce this?
I just tried this and it still fails: I haven't checked, but I assume the "incorrect version format" is precisely because there's still some error such as "cannot open shared object file" being reported. (That's what used to happen.) Note that I have ; maybe that's important to reproduce the problem.
It looks like has something to do with this because when I switched to I also got the same "incorrect version format" error. I printed the output of () and apparently doesn't generate any output. I'm not sure if that is relevant.
That's stdout; what does stderr say?
Ah yep, it's the "unable to load shared libraries" error message:
Inspecting the failing binary shows it isn't able to find or : Should bootstrap be fiddling with or setting when compiling/running? I was able to make things work by setting to the stage1 directory.
The error is about though, not or . I think already sets .
The error you got first is a different one though. Possibly it's not loading the codegen backend. Can you try instead of ?
Ah, good to know. That's odd... Given the dependency chain , on my machine the first link is broken while it looks like the second link is broken for you. This is what I see when looking at the dependencies for . Looks like it's picking up LLVM just fine :manshrugging:
Even on your machine . So far it doesn't look like there is a difference between our machines. FWIW, this also works here: Probably sets some other LDLIBRARYPATH...
It sounds like the only change that needs to happen is setting LDLIBRARYPATH correctly?
Possibly?

I don't know anything about our LDLIBRARYPATH handling.^^
Based on these comments on Zulip from ... we should set whenever running a tool, probably somewhere around . Is that the correct interpretation? Otherwise we could explicitly add the sysroot to the , which is effectively what you meant when you said
So it looks like the issue is that we need some way to tell tools where to find LLVM and the other dynamic libraries it needs. What I've done is found where we create the which runs the tools, then inside an I have tried: Setting the command's (or rather, the result of ) environment variable to include the sysroot, or Just set the command's current working directory to the sysroot The places I've tried making this modification are:  in because it creates the used to run a tool, and  because the the command seems to do a and that is where we start constructing its I believe the fix for this issue should only take a couple lines, but I don't know where to put them because of my unfamiliarity with Rustbuild. I wouldn't be surprised if I was actually doing the right thing, but trying to link to the wrong stage or something. do you have any pointers?
Those sound like questions for
tool_cmd sounds like the right place to me at a high level, yes - it'll be hard for me to be sure without rebuilding all of the context, but if you propose a PR that'll make it easier for me to evaluate. I don't think there's necessarily a "right place", if you find something that works for the stage 0 tools pretty much across the board that would be good enough most likely.
I don't think it is a good idea to change the working directory; the tool might be invoked with relative paths that would then not work any more. But I also have no idea how the working directory is even determined currently. However, I also don't see why that would even help. The RPATH is set to , so the working directory dos not matter, does it?
Moreover, does not even seem involved here? I some debugging output but it doesn't show. The code that invokes the tool from bootstrap looks like
Oh, that seems wrong. IIRC we generally don't build+run in one step, rather we run cargo build and then toolcmd on the binary?

Setting up the environment in preparetool_cargo seems feasible, too, though.
We do already modify this variable in some places, but I don't think in a very principled way (so I'm not terribly surprised it's not working). I'm not sure I have enough time to investigate though, unfortunately.
We later want to do in the Miri crate and that has all the same problems. I doubt we want to re-do all the logic of . So given that has to work, why is using wrong? Also, this does not build+run in one step. The build already happened earlier. But we use for running since it does a lot of path setup for us. Which variable? I did some more experiments and I can confirm that adding to the LDLIBRARYPATH helps. Now the part works. However, still fails, because something is overwriting our LDLIBRARYPATH with something else and thereby removes the LLVM dir from it...
Okay, I found who's overwriting LDLIBRARYPATH, it was . Here's my hackfix that makes work with the downloaded LLVM: I hope at some point someone can take this and turn it into something proper. ;)
It is also worth noting that this is a regression -- testing Miri on stage 0 used to work just fine some time in summer/fall last year. I have no idea which rustbuild change broke things, though. EDIT: ah I remember, it's probably the pre-built LLVM download.
So how can we make progress on this? I produced a working diff above, but it's a crude hack and only fixes the problem for Miri. I don't know nearly enough about rustbuild to figure out the proper fix for this though -- there are lots of moving pieces here, so this is unlikely to be fixed until someone from the rustbuild team can take a look. That would be much appreciated. :)
there is not really a rustbuild team - there's me and Mark-Simulacrum, and ehuss has a fair bit of knowledge I think. I'm on break for a while and Simulacrum is always busy.
I mean, I guess that makes you two (or three) the rustbuild team. At least this is exactly how I became part of the Miri and const-eval teams.

;)
Regarding the problem at hand, I could probably try patching so that it sets up to include (hopefully I can check to only do this when we are actually using CI LLVM). But would that make any sense?
sure, that seems reasonable.
Reopening as the issue persists for errorindexgenerator specifically, which has some custom logic for dylib paths that still needs adjusting:
the error index is already tracked by