Fix windows support #99
Conversation
To successfully build jemalloc for msvc-windows, we need to pretend we're doing a mingw build. The configure script will then check if the compiler is actually an MSVC compiler (by checking if it defines _MSC_VER), and if so switch to an MSVC build (which enables a bunch of compatibility hacks, such as removing the need for pthread). Signed-off-by: roblabla <unfiltered@roblab.la>
On windows, the generated library is called jemalloc_s instead of jemalloc_pic. Signed-off-by: roblabla <unfiltered@roblab.la>
Signed-off-by: roblabla <unfiltered@roblab.la>
It turns out, jemalloc doesn't support having unprefixed malloc on these targets. When --with-jemalloc-prefix is not specified, jemalloc will implicitly add a `je_` prefix regardless. Signed-off-by: roblabla <unfiltered@roblab.la>
roblabla
force-pushed
the
windows-support
branch
from
b7da974
to
2afe5b8
Compare
|
Interesting, you can also update the action files to add windows target and prove it works. |
|
So as I said, I have a bit of a weird setup where I use a cross-compiling toolchain to build the crate, and that works. However, when I tried to add it in CI, but doing the naive thing of just running This might be fixable by entering a visual studio shell so the cl.exe program is in the PATH. I'll give it a try. |
|
I don't think space in path is the problem.
The line shows that full compiler path is used. However the target it tries doesn't match the compiler it uses. |
|
The space is absolutely the problem, but the logs don't show it clearly. If I run the build locally on a windows vm and check the config.log, it has an error to the tune of "C:\Program: no such file or directory", which stops the build. Autoconf does not support spaces in the compiler path. It's a rather well-known problem. I just had a pretty solid idea to avoid it though: I can use the short path syntax (c:\progra~2) to avoid the space 👀. The target is not wrong. As I explain in the post, the way you do an msvc build with jemalloc is by building for mingw/cygwin with an msvc compiler in CC. The autoconf script will detect that and set use_msvc to yes, at which point the msvc codepaths will be used. |
jemalloc-sys/build.rs
Outdated
| let path = match Command::new("cmd").args(["/c", "@echo %~s1"]).arg(orig_path).output() { | ||
| Ok(v) if v.status.success() => v.stdout, | ||
| Ok(v) => { | ||
| warning!("Failed to expand {} to a short path, the command exited with status {}", orig_path.display(), v.status); |
| @@ -9,13 +9,19 @@ on: | |||
| branches: | |||
| - 'master' | |||
| - 'main' | |||
| - 'windows-support' | |||
There was a problem hiding this comment.
Should be deleted before being merged.
| // PathBuf. | ||
| let path = match String::from_utf8(path) { | ||
| Ok(v) => v, | ||
| Err(_err) => { |
roblabla
force-pushed
the
windows-support
branch
16 times, most recently
from
0d52502
to
be3cb2b
Compare
Autoconf does not support spaces in the compiler path. This is not usually a problem, as on most platforms, the compiler will reside in a path without spaces (such as /usr/bin or /opt). However, on windows, the MSVC compiler is usually found under C:\Program Files, which causes all hell to break loose. Thankfully, windows has something called "Short Paths", which we can use to turn C:\Program Files into C:\PROGRA~2, eliminating the path. If the build script detects the compiler path has a space, and is running on windows, it will attempt to turn the path into a short path and run with this.
roblabla
force-pushed
the
windows-support
branch
from
94e2f54
to
106827e
Compare
roblabla
force-pushed
the
windows-support
branch
2 times, most recently
from
8c73dde
to
85913f9
Compare
roblabla
force-pushed
the
windows-support
branch
3 times, most recently
from
f4a03db
to
4ec1604
Compare
roblabla
force-pushed
the
windows-support
branch
from
4ec1604
to
ca6616a
Compare
The windows targets weren't working at all for me:
i686-pc-win32doesn't exist as far as jemalloc's build system is concerned, onlyi686-pc-mingw32does (and if jemalloc detects the compiler is MSVC, it will automatically switch to an MSVC-based build).Finally, I also added support for the
win7target, which is a tier3 target supporting windows 7.Note that this is tested manually on my end using a bit of a bespoke cross-compilation toolchain. The crate doesn't successfully build on a more "normal" toolchain due to autoconf failing to build when the compiler path contains spaces. I'd like to add a CI, but I'd need to first need to find a way to fix that issue...