`make install` error on Windows

[mrec]

Trying to build latest on Win7-64, on a freshly-installed MSYS. The previous make check-fast mostly worked, with only one failure. (See #13439 - @klutzy has already commented on that.)

tmp/dist/rust-0.11-pre-i686-pc-mingw32/install.sh: line 387: /home/Mike/rust/tmp/dist/rust-0.11-pre-
i686-pc-mingw32//lib/rustlib/manifest.in: No such file or directory
install: verifying installed binaries are executable
tmp/dist/rust-0.11-pre-i686-pc-mingw32/install.sh: line 393: /usr/local/bin/rustc: No such file or d
irectory
install: error: can't execute installed rustc binary. installation may be broken. if this is expecte
d then rerun install.sh with `--disable-verify` or `make install` with `--disable-verify-install`
/home/Mike/rust/mk/install.mk:18: recipe for target `install' failed
make: *** [install] Error 1

Possibly relevant:

• the double slash in the manifest.in path
• I have a ~/rust/tmp/dist/rust-0.11-pre-i686-pc-mingw32 folder, but no lib under it
• I don't have a /usr folder at all

[alexcrichton]

cc @brson

[iliekturtles]

Just ran into the same issue. After some digging I've found that configure sets CFG_LIBDIR to $PREFIX/lib on Linux and $PREFIX/bin on mingw32. See the make install output at the bottom of the post. install.sh has a number of locations that assume $PREFIX/lib including line 387. I'll see about submitting a pull request that removes these assumptions.

I'm not sure what should be done about the /usr error. Should this be considered a MSYS setup issue? This is the default directory if configure is run without prefix. I also saw the double slashes. These have no affect on the path, and in my case were caused by running configure --prefix=.../dest/dir/ -- the trailing slash is added by MSYS' tab completition and isn't expected or stripped out by configure.

Linux, note liblibc-*.so directory:

cfg: build triple x86_64-unknown-linux-gnu
cfg: host triples x86_64-unknown-linux-gnu
cfg: target triples x86_64-unknown-linux-gnu
cfg: enabling more debugging (CFG_ENABLE_DEBUG)
cfg: host for x86_64-unknown-linux-gnu is x86_64
cfg: os for x86_64-unknown-linux-gnu is unknown-linux-gnu
cfg: using gcc
cfg: no pdflatex found, deferring to xelatex
cfg: no xelatex found, deferring to lualatex
cfg: no lualatex found, disabling LaTeX docs
cfg: no pandoc found, omitting PDF and EPUB docs
cfg: no llnextgen found, omitting grammar-verification
cfg: including prepare rules
cfg: including dist rules
cfg: including install rules
cleaning destination tmp/dist/rust-0.11.0-pre-x86_64-unknown-linux-gnu
prepare: tmp/dist/rust-0.11.0-pre-x86_64-unknown-linux-gnu/bin
prepare: tmp/dist/rust-0.11.0-pre-x86_64-unknown-linux-gnu/lib
prepare: tmp/dist/rust-0.11.0-pre-x86_64-unknown-linux-gnu/share/man/man1
prepare: tmp/dist/rust-0.11.0-pre-x86_64-unknown-linux-gnu/lib/liblibc-*.so
...

mingw32, note libc-*.dll directory:

cfg: build triple i686-pc-mingw32
cfg: host triples i686-pc-mingw32
cfg: target triples i686-pc-mingw32
cfg: enabling more debugging (CFG_ENABLE_DEBUG)
cfg: host for i686-pc-mingw32 is i386
cfg: os for i686-pc-mingw32 is pc-mingw32
cfg: using gcc
cfg: disabling valgrind due to its unreliability on this platform
cfg: no pdflatex found, deferring to xelatex
cfg: no xelatex found, deferring to lualatex
cfg: no lualatex found, disabling LaTeX docs
cfg: no pandoc found, omitting PDF and EPUB docs
cfg: no llnextgen found, omitting grammar-verification
cfg: including prepare rules
cfg: including dist rules
cfg: including install rules
cleaning destination tmp/dist/rust-0.11.0-pre-i686-pc-mingw32
prepare: tmp/dist/rust-0.11.0-pre-i686-pc-mingw32/bin
prepare: tmp/dist/rust-0.11.0-pre-i686-pc-mingw32/bin
prepare: tmp/dist/rust-0.11.0-pre-i686-pc-mingw32/share/man/man1
prepare: tmp/dist/rust-0.11.0-pre-i686-pc-mingw32/bin/libc-*.dll
...

[mrec]

Re the possibility of the missing /usr being an MSYS setup issue, I did raise one at the time that might be related, but didn't get much of a response.

[mrec]

Actually, scratch that, I was just misunderstanding how MSYS set things up. I think I was misled by /usr not appearing in Explorer under the msys root, but /usr within the MSYS shell seems to be the MSYS root.

[brson]

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 configure/install.sh may be either relative to cwd or absolute.

The root of the issue is that on windows we don't use a lib directory, but stuff everything into bin. The reason we do this is to hack around Window's lack of options for locating dynamic libs at runtime.

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 $PATH variable at install time to make this entire difference go away.

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 /usr/local/lib.

Note that overriding --libdir is super-prone to utter breakage, both at compile time - when locating crates, and also at runtime - when dynamically loading libraries.

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 configure to install.sh and special-casing mingw to look in $prefix/bin for the install manifest.

[iliekturtles]

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.

[pnkfelix]

@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.

[brson]

That would be swell @pnkfelix. Thanks
On May 19, 2014 4:08 PM, "Felix S Klock II" notifications@github.com
wrote:

@brson https://github.com/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.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13810#issuecomment-43569466
.