Wine: "build_command_line command line too long"
GreySideMM opened this issue · 6 comments
This title might be wrong, tho:
We try to compile a larger project (11 MB .dll file as result) but the very last step, the linking, gets stuck and never ends. There are no error messages, the log files in /tmp are existent but empty. So I caught the command line and run it on my own - but not thru wine-msvc.sh. So winetricks and other stuff might be missing then but I at least got this error message from wine:
"build_command_line command line too long"
Sorry for not posting the rest of the output but the incredible long command line of around 37kB length messed up my shell quite a bit.
So if this error message is not only due to omitting your wine-msvc.sh then then this should be the error. I couldn't find anything about this online. I do not know if there is a way of cmake or MSVC to simply split it up into several commands.
The missing error log might be a separate issue to fix, I guess.
Thank you for your help!
Many build tools try to avoid such long paths when they are building on actual Windows, by storing the command line in a .rsp file, and passing that like @args.rsp. But when the build tools are running on Unix, they might not think they need to do this - I'm not sure what the common case is here, or how many of the projects people have tried where this really matters though.
Thank you for your advice and the tip. I tried to alter the msvc-wine.sh in different ways but it didn't work out.
str="${ARGS[@]}"
if [[ ${#str} -gt 20000 ]]
then
echo $str > args.rsp
WINEDEBUG=-all wine64 "$EXE" "@args.rsp" &>/dev/null &
pid=$!
sed -E "$WINE_MSVC_STDOUT_SED" <$WINE_MSVC_STDOUT || kill $pid &>/dev/null &
sed -E "$WINE_MSVC_STDERR_SED" <$WINE_MSVC_STDERR >&2 || kill $pid &>/dev/null &
wait $pid &>/dev/null
else
WINEDEBUG=-all wine64 "$EXE" "${ARGS[@]}" &>/dev/null &
pid=$!
sed -E "$WINE_MSVC_STDOUT_SED" <$WINE_MSVC_STDOUT || kill $pid &>/dev/null &
sed -E "$WINE_MSVC_STDERR_SED" <$WINE_MSVC_STDERR >&2 || kill $pid &>/dev/null &
wait $pid &>/dev/null
fi
(Pls don't mind this terrible code, I'm not good at all writing bash scripts.)
Instead of the @args.rps I also tried the bash version like "$(< args.rsp)". It fails in a different way.
The output of the compile looks now like this:
: && /usr/bin/cmake -E vs_link_dll --intdir=CMakeFiles/YimMenu.dir --rc=/home/reaper/my_msvc/opt/msvc/bin/x64/rc --mt=/home/reaper/my_msvc/opt/msvc/bin/x64/mt --manifests -- /home/reaper/my_msvc/opt/msvc/bin/x64/link /nologo CMakeFiles/[...] [...].lib && :
LINK: command "/home/reaper/my_msvc/opt/msvc/bin/x64/link /nologo CMakeFiles/[...] [...].dll.manifest" failed (exit code 2) with the following output:
ninja: build stopped: subcommand failed.
Do I need to make changes to the msvc/bin/ scripts as well? But I would assume they just pass the "@args.rsp" as simple text along.
I could also try and alter the wine src by itself as the limit of 32767 bytes is hardcoded, but I guess that will simply crash it.
There are several people working on this project who simply ended up running a Windows VM to circumvent this issue.
So I could make changes to the wine-msvc.sh to get it to compile. I had an error in the previous code that's fixed now. But it's still pretty, pretty whacky.
argsstr="${ARGS[@]:1}"
if [[ ${#argsstr} -gt 30000 ]]
then
echo "${ARGS[@]:1}" > args.rsp
WINEDEBUG=-all wine64 "$EXE" "${ARGS[@]:0:1}" "@args.rsp" &>/dev/null &
pid=$!
sed -E "$WINE_MSVC_STDOUT_SED" <$WINE_MSVC_STDOUT || kill $pid &>/dev/null &
sed -E "$WINE_MSVC_STDERR_SED" <$WINE_MSVC_STDERR >&2 || kill $pid &>/dev/null &
wait $pid &>/dev/null
else
WINEDEBUG=-all wine64 "$EXE" "${ARGS[@]}" &>/dev/null &
pid=$!
sed -E "$WINE_MSVC_STDOUT_SED" <$WINE_MSVC_STDOUT || kill $pid &>/dev/null &
sed -E "$WINE_MSVC_STDERR_SED" <$WINE_MSVC_STDERR >&2 || kill $pid &>/dev/null &
wait $pid &>/dev/null
fi
In theory - and that would be the far better solution - cmake could be forced to use response files. But it fails for me with argument errors. Or cmake gets stuck and never finishes the build (not the compile itself) without an error. Also it's not really documented and I couldn't find much.
set(CMAKE_C_USE_RESPONSE_FILE_FOR_OBJECTS TRUE)
set(CMAKE_CXX_USE_RESPONSE_FILE_FOR_OBJECTS TRUE)
set(CMAKE_NINJA_FORCE_RESPONSE_FILE TRUE)
Leaving this info here for others. My script code should be made way nicer if you actually want to implement this hacky solution.
So I could make changes to the wine-msvc.sh to get it to compile. I had an error in the previous code that's fixed now. But it's still pretty, pretty whacky.
argsstr="${ARGS[@]:1}" if [[ ${#argsstr} -gt 30000 ]] then echo "${ARGS[@]:1}" > args.rsp WINEDEBUG=-all wine64 "$EXE" "${ARGS[@]:0:1}" "@args.rsp" &>/dev/null & pid=$! sed -E "$WINE_MSVC_STDOUT_SED" <$WINE_MSVC_STDOUT || kill $pid &>/dev/null & sed -E "$WINE_MSVC_STDERR_SED" <$WINE_MSVC_STDERR >&2 || kill $pid &>/dev/null & wait $pid &>/dev/null else WINEDEBUG=-all wine64 "$EXE" "${ARGS[@]}" &>/dev/null & pid=$! sed -E "$WINE_MSVC_STDOUT_SED" <$WINE_MSVC_STDOUT || kill $pid &>/dev/null & sed -E "$WINE_MSVC_STDERR_SED" <$WINE_MSVC_STDERR >&2 || kill $pid &>/dev/null & wait $pid &>/dev/null fi
Right - that's indeed a bit hacky, but great if it fixes the issue for you!
In theory - and that would be the far better solution - cmake could be forced to use response files. But it fails for me with argument errors. Or cmake gets stuck and never finishes the build (not the compile itself) without an error. Also it's not really documented and I couldn't find much.
Nice! Btw, see #93 and #96, for an attempt at fixing issues with cmake generated .rsp files.
So I am wondering why you not "simply" use the Windows build of cmake? Shouldn't that fix this issue by itself?
Unrelated but wouldn't fit a new issue (as well, its not about this project):
Everyone ever managed to setup VSCode with IntelliSense properly? It setup includes for MSVC imo correct. But I keep getting all sorts of (syntax) errors. Tried clang as alternative but didn't work as well.
So I am wondering why you not "simply" use the Windows build of cmake? Shouldn't that fix this issue by itself?
If you want to use the Windows build of cmake, you certainly are free to do that - I've heard from users doing that, and that way, one can avoid some of the issues that we do have.
But that makes for a quite different build setup/environment - then you run cmake wrapped in wine, and ninja wrapped in wine, and the whole build is essentially run in wine. The way msvc-wine currently works is that all of the builds are orchestrated in unix land, easing builds where as much as possible is run as unix tools, handling cases where some build tools are native unix tools while only the MSVC compilers are run in wine. That's essentially a different goal than what msvc-wine has.