-
Notifications
You must be signed in to change notification settings - Fork 13.3k
rustbuild changes to build LLVM #32599
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -16,6 +16,29 @@ use std::process::Command; | |
use bootstrap::{dylib_path, dylib_path_var}; | ||
use filetime::FileTime; | ||
|
||
#[cfg(not(windows))] | ||
pub fn build_path(path: &str) -> PathBuf { | ||
PathBuf::from(path) | ||
} | ||
|
||
#[cfg(windows)] | ||
pub fn build_path(path: &str) -> PathBuf { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hm this seems very suspicious about how this would be called, how are MSYS paths leaking into the configuration here? Are the makefiles encoding MSYS paths? Also, this can probably be done in Rust like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The I'm not sure what the logic is to convert to Windows paths, so I'd rather avoid writing that. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The logic should be pretty simple, right? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's only the Windows paths in msys form. There are also things like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Right so this can cause problems, but this happens on every startup of the build system, so it would be best to spawn fewer processes and just catch up on edge cases over time. The vast majority of these paths will just be There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Or actually, even better, we should change the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't want to touch that script though. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think we can stomach all of these process spawns on every invocation of the build system, so this needs to be handled in some method. |
||
use std::io::{stderr, Write}; | ||
use build_helper::output; | ||
|
||
if path.chars().next() == Some('/') { | ||
let output = output(&mut Command::new("cygpath").arg("-w").arg(path)); | ||
let win_path = output.trim_right(); | ||
writeln!(&mut stderr(), | ||
"note: Converted Unix path '{}' to Windows path '{}'", | ||
path, | ||
win_path).ok(); | ||
PathBuf::from(win_path) | ||
} else { | ||
PathBuf::from(path) | ||
} | ||
} | ||
|
||
pub fn staticlib(name: &str, target: &str) -> String { | ||
if target.contains("windows-msvc") { | ||
format!("{}.lib", name) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a comment to this explaining that this is just ensuring that we can run binaries like
llvm-config
and the compiler by ensuring that the dynamically linked libraries are inPATH
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also seems relevant for all platforms (not just Windows), so perhaps this could create a variable like
ldpath
to handle the Unix/OSX cases?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't needed on Linux atleast, since it links using full paths and not just the filename,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this needed for running
llvm-config
at all? Or running the compiler if it's dynamically linked? I may be misunderstanding the purpose for this though?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not need for
llvm-config
on Windows, since it's in the directory with the DLLs. It is needed for executables which are not in the LLVM's binary directory which link dynamically to LLVM (like rustc).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, but that's not a Windows specific limitation, right? If rustc ever dynamically links to LLVM (on any platform) we need the library directory to be in the dynamic library path?
It looks like the difference is just that the dynamic library directory on Windows happens to be the same as the binaries directory?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is Windows specific, as you link with filenames on Windows and not paths.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I think I'm not being clear enough. So if you're liking with an external LLVM that is itself dynamically linked, then the only hope we have of working correctly is to ensure that the directory with that LLVM dynamic library is in the runtime linker lookup path. On Windows this just happens to be
PATH
but on Linux/OSX this idLD_LIBRARY_PATH
andDYLD_LIBRARY_PATH
.Which is to say, if we link to a dynamically linked LLVM on any platform, we need to run this logic to ensure that the relevant directory is in the relevant environment variable.