If the linker is invoked with --chroot /foo and /bar/baz.o, it
tries to read the file from /foo/bar/baz.o. This feature is useful
when you are dealing with files created by the --reproduce option.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
I uploaded reproduce for which this patch fails currently here: https://drive.google.com/file/d/0B_OWr6ld9gUmSXhjM0g4Y3I3d3c/view
In short- reproduce contains script that tries to open "/lib/x86_64-linux-gnu/libc.so.6" file. When running under windows,
callstack is
lld.exe!lld::elf::error(const llvm::Twine & Msg) Line 100 C++ lld.exe!lld::elf::ScriptLexer::setError(const llvm::Twine & Msg) Line 89 C++ > lld.exe!`anonymous namespace'::ScriptParser::addFile(llvm::StringRef S) Line 275 C++ lld.exe!`anonymous namespace'::ScriptParser::readGroup() Line 310 C++ lld.exe!`anonymous namespace'::ScriptParser::readLinkerScript() Line 222 C++
That happens because sys::patch::is_absolute called from addFile uses native style by default and
returns false for /lib/x86_64-linux-gnu/libc.so.6" under windows.
With a little modification for above, patch works for me though. I uploaded changed version:
It looks fine for me.
Approach LGTM, modulo @grimar's issue. I wonder if we should call the option --sysroot (and make it available to users) though? We'd have a little more work to do to handle a user-supplied sysroot when creating reproducers.