You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The pkg_config utility is nominally cross-platform, so successfully building crates which use it--usually via a utility crate like pkg-config-rs--should be feasible. However, such crates don't currently build (e.g. tcod-sys). This will probably not be as simple as installing pkg_config via a package manager, but that is a good start.
The actual issue is that older versions of the gcc crate did not emit the /Fo flag to tell cl.exe where to put object files created during compilation, and thus object files are created in the working directory. These object files are cleaned up after compilation, so this usually doesn't matter, but since the working directory (which contains the crate's source code) is mounted read-only in the container, cl.exe can't create them. Curiously, this only results in an error when the linker goes looking for the object file, not when cl.exe tries to write it.
I don't think there's a good work-around besides mounting the working directory as read/write instead of read-only. I think this is probably not worth it, but I'll let @pietroalbini have the final word.
The text was updated successfully, but these errors were encountered:
ecstatic-morse
changed the title
Crates which depend on pkg_config do not build on Windows
Crates which depend on gcc do not build on Windows
Jul 23, 2019
Ugh, it appears that the release of gcc (v0.3.53) used by tcod-sys has the code to emit /Fo. TARGET is set correctly as well. Not sure why it doesn't end up on the command line.
In any case, I can reproduce this when compiling on the host with tcod-rs v0.12.0. The working directory is populated with object files after building.
ecstatic-morse
changed the title
Crates which depend on gcc do not build on Windows
Crates which depend on old versions of gcc (now cc) do not build on Windows
Jul 23, 2019
Thepkg_config
utility is nominally cross-platform, so successfully building crates which use it--usually via a utility crate likepkg-config-rs
--should be feasible. However, such crates don't currently build (e.g.tcod-sys
). This will probably not be as simple as installingpkg_config
via a package manager, but that is a good start.The actual issue is that older versions of the
gcc
crate did not emit the/Fo
flag to tellcl.exe
where to put object files created during compilation, and thus object files are created in the working directory. These object files are cleaned up after compilation, so this usually doesn't matter, but since the working directory (which contains the crate's source code) is mounted read-only in the container,cl.exe
can't create them. Curiously, this only results in an error when the linker goes looking for the object file, not whencl.exe
tries to write it.I don't think there's a good work-around besides mounting the working directory as read/write instead of read-only. I think this is probably not worth it, but I'll let @pietroalbini have the final word.
The text was updated successfully, but these errors were encountered: