![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
TMI: Adventures in library loading
May. 2nd, 2013 06:18 pmLife does not, apparently, go on as fast as one hopes; yesterday I was too exhausted and depressed to work and took a day off. To which I credit me being semi-functional today.
In any case, today I learned about the magic of rustc's filesearch module. What seems like eons ago but probably only a week ago, I set up some wacky symbolic link inside my build directory to get rustpkg to be able to find the core library. After pulling a new LLVM version, I had to blow away my build directory, as one often does. And thus, the rustpkg tests no longer ran because once again, it couldn't find core. And of course, the same thing happened on the bots, causing tests to fail, because my hack was a truly terrible hack (that only worked on my local machine).
rustc infers the sysroot -- which is the root directory that it uses for searching for standard libraries -- from the name of the executable you're running. Keep in mind that rustc is just-a-library so there's more than one possible executable name. Most executables sit under build/x86_64-apple-darwin/stage2/bin/whatever in our build system (not even talking about installed builds here, just in-place builds). The stages refer to the stages of compiler bootstrapping, but for testing we usually run stage 2. And of course, the host and But it happens that the test executable containing all the #[test] functions lives in build/x86_64-apple-darwin/tests/ and so the parent directory getting inferred was totally wrong. The answer is basically for me to just add in some terrible hacks to override the sysroot from my test functions, but it took me a while to get to that.
They didn't tell me in grad school that there'd be days like these...
In any case, today I learned about the magic of rustc's filesearch module. What seems like eons ago but probably only a week ago, I set up some wacky symbolic link inside my build directory to get rustpkg to be able to find the core library. After pulling a new LLVM version, I had to blow away my build directory, as one often does. And thus, the rustpkg tests no longer ran because once again, it couldn't find core. And of course, the same thing happened on the bots, causing tests to fail, because my hack was a truly terrible hack (that only worked on my local machine).
rustc infers the sysroot -- which is the root directory that it uses for searching for standard libraries -- from the name of the executable you're running. Keep in mind that rustc is just-a-library so there's more than one possible executable name. Most executables sit under build/x86_64-apple-darwin/stage2/bin/whatever in our build system (not even talking about installed builds here, just in-place builds). The stages refer to the stages of compiler bootstrapping, but for testing we usually run stage 2. And of course, the host and But it happens that the test executable containing all the #[test] functions lives in build/x86_64-apple-darwin/tests/ and so the parent directory getting inferred was totally wrong. The answer is basically for me to just add in some terrible hacks to override the sysroot from my test functions, but it took me a while to get to that.
They didn't tell me in grad school that there'd be days like these...