-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Fixes to cfg .mk files for Windows #21065
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
Conversation
…able on Windows as is done for other platforms, and added GCC flag to ensure MINGW's ANSI compatible STDIO functions are used wherever available (required by jemalloc).
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see CONTRIBUTING.md for more information. |
Removed use of unused LDPATH variable on Windows as is done for other platforms, and added GCC flag to ensure MINGW's ANSI compatible STDIO functions are used wherever available (required by jemalloc). Without these changes it ends up setting the PATH twice, and the second time the PATH begins with `:` which is invalid. Also the regular msvcrt printf-like functions would be used which don't understand stuff like %hhd and %z which jemalloc uses. This change ought not to make any difference to the output but it fixes the build process for me since at least my build environment couldn't handle that broken path caused by LDPATH being empty.
re-assigning to brson since he gave the r+ |
As far as I can tell one of the linux tests failed for some reason that has nothing to do with my changes and it's completely ruined any chance of seeing if my changes actually caused any problems because 'no point in continuing' ... Unless there's any evidence to the contrary or that this change is bad (I can't see any) I suggest ignoring that run-pass/unfold-cross-crate.rs failure on linux and let it run through the test system again. Thanks... |
Looks like this might need a rebase. |
Removed use of unused LDPATH variable on Windows as is done for other platforms, and added GCC flag to ensure MINGW's ANSI compatible STDIO functions are used wherever available (required by jemalloc). Without these changes it ends up setting the PATH twice, and the second time the PATH begins with `:` which is invalid. Also the regular msvcrt printf-like functions would be used which don't understand stuff like %hhd and %z which jemalloc uses. This change ought not to make any difference to the output but it fixes the build process for me since at least my build environment couldn't handle that broken path caused by LDPATH being empty.
Removed use of unused LDPATH variable on Windows as is done for other platforms, and added GCC flag to ensure MINGW's ANSI compatible STDIO functions are used wherever available (required by jemalloc).
Without these changes it ends up setting the PATH twice, and the second time the PATH begins with
:
which is invalid. Also the regular msvcrt printf-like functions would be used which don't understand stuff like %hhd and %z which jemalloc uses.This change ought not to make any difference to the output but it fixes the build process for me since at least my build environment couldn't handle that broken path caused by LDPATH being empty.