make install error on Windows
#13810
Comments
|
cc @brson |
|
Just ran into the same issue. After some digging I've found that I'm not sure what should be done about the Linux, note liblibc-*.so directory: mingw32, note libc-*.dll directory: |
Replaced literal 'lib' with source relative lib directory. mingw32 uses 'bin' instead of 'lib'. Closes rust-lang#13810.
|
Re the possibility of the missing |
|
Actually, scratch that, I was just misunderstanding how MSYS set things up. I think I was misled by |
|
I'm assuming that per #14284 fixing this one line solves this entire issue. Unfortunately the subtleties here are pretty deep. The solution proposed in #14284 makes several assumptions about relative paths that don't hold: all path-related options The root of the issue is that on windows we don't use a I think I prefer to continue using this strategy of having a different filesystem layout on windows, though we may also be able to just add more to the In any case, I would like to purge this difference in layouts from the build process, and defer the decision on where to put various artifacts until install-time. So, when we produce our dist artefacts, they have the same internal layout on all platforms, and the build system is less complex. Doing that would solve this issue since then the manifest would be at the same location on all platforms. If we do that then we have some options: since this installer is explicitly for Unixy systems (here msys), we may not need to mess with --libdir at all, if msys has previously set up the paths correctly to dynamically load libs from Note that overriding After writing all this I'm more convinced that the right solution is to remove this hacky difference in filesystem layout completely. In the meantime though I am not opposed to copying some of the platform-detection code from |
|
Thanks for the feedback. I was fearing it wouldn't be so simple. I'll start taking a look at the short-term solution of copying some of the platform detection code. No promises on time if someone else wants to pick this up before I get a chance to submit something for review. |
|
@brson after all of my check-stage1 work I am more familiar with the issues involved here (in terms of both the logic dictating where libraries are emitted and the dynamic library resolution process on various platforms), so I can try to poke at this if you like. |
|
That would be swell @pnkfelix. Thanks
|
Platform-detection code from `configure` copied over to `install.sh` in order to special case the lib dir being `bin` on Windows instead of `lib`. Short-term fix for rust-lang#13810.
…r=brson Short-term fix per @brson's comment: #13810 (comment). Tested on Win7 x64 and Linux. One possible issue is that `install.sh` doesn't have a `need_cmd` definition like `configure` does. Should this be ported over as well? Platform-detection code from `configure` copied over to `install.sh` in order to special case the lib dir being `bin` on Windows instead of `lib`. Short-term fix for #13810.
|
P-low, not 1.0. |
|
How relevant is this issue today? I don't have a Windows machine... |
|
Our installers have changed quite a bit since this was opened, so I'm going to close this as "probably fixed" |
Add action to expand a declarative macro once, inline. Fixes rust-lang#13598 This commit adds a new r-a method, `expandMacroInline`, which expands the macro that's currently selected. See rust-lang#13598 for the most applicable issue; though I suspect it'll resolve part of rust-lang#5949 and make rust-lang#11888 significantly easier). The macro works like this:  I have 2 questions before this PR can be merged: 1. **Should we rustfmt the output?** The advantage of doing this is neater code. The disadvantages are we'd have to format the whole expr/stmt/block (since there's no point just formatting one part, especially over multiple lines), and maybe it moves the code around more in weird ways. My suggestion here is to start off by not doing any formatting; and if it appears useful we can decide to do formatting in a later release. 2. **Is it worth solving the `$crate` hygiene issue now?** -- I think this PR is usable as of right now for some use-cases; but it is annoying that many common macros (i.e. `println!()`, `format!()`) can't be expanded further unless the user guesses the correct `$crate` value. The trouble with solving that issue is that I think it's complicated and imperfect. If we do solve it; we'd also need to either change the existing `expandMacro`/`expandMacroInline` commands; provide some option to allow/disallow `$crate` expanding; or come to some other compromise.
Currently https://rust-lang.github.io/rust-clippy/master/index.html#wildcard_dependencies doc doesn't contain explanation how it should be so added more details ---- changelog: none
Trying to build latest on Win7-64, on a freshly-installed MSYS. The previous
make check-fastmostly worked, with only one failure. (See #13439 - @klutzy has already commented on that.)Possibly relevant:
manifest.inpath~/rust/tmp/dist/rust-0.11-pre-i686-pc-mingw32folder, but nolibunder it/usrfolder at allThe text was updated successfully, but these errors were encountered: