The problem persists with Swift 5.4.3 and 5.5 (Development).
Could SPM maybe at least output more information (with the "-v" option) after displaying "...\swiftxml-manifest.exe -handle ..." so one could see what goes wrong?
What exactly do you expect to display here? This is a subprocess that the the SPM process is waiting on. The current state is all the information that the process has. Perhaps to draw some inspiration - do you know of any bash flags to debug a pipe in a command? (e.g. the pipe here: seq 1 2 | echo).
All I know that the last info that "-v" gives me is that the process called (or wanted to call??) a program that when the process gets stuck does not exist any more. I do not have further insight, my guess would be that the process got stuck after that program had been running (and then deleted), so further information about what the process intends to do next would be nice to have. Maybe that is some misinterpretation.
SPM just gets stuck again and again like this at some point, with different (and very simple) projects, and not only on my Windows installations, but also confirmed by others, and with projects that are running fine on macOS and on Linux. My hope was that somebody who has some more insight than me could guess what the issue is and maybe add something to the execution of the SPM that could give some further insight. Just a hope.
Hmm, wait, the process does not exist? What that implies is that the process either
a) failed to launch - bad environment, missing dependency, ...
b) failed to exit properly - fatalError, invalid memory access, ...
In either case, that is something that SPM should catch and report as a failure. The subprocess is created at https://github.com/apple/swift-package-manager/blob/2d7b2bcc529e5ac9ef8a90bca89d74b3ef39f1c6/Sources/PackageLoading/ManifestLoader.swift#L804
and the result is checked at https://github.com/apple/swift-package-manager/blob/2d7b2bcc529e5ac9ef8a90bca89d74b3ef39f1c6/Sources/PackageLoading/ManifestLoader.swift#L813-L816
I don't have any way to diagnose this any further as I've been unable to reproduce this behavior on my personal machine as well as the various package CIs that I have setup.
The program file whose path is in the last output in the command line does not exist any more when SPM gets stuck. Once I had seen the directory of that program a very short time in %TEMP%.
(Note also that all virus protection etc. of Windows were turned off, normally I would suspect some virus protected falsely deleting a file.)
The file is temporary and meant to be cleaned up. That is expected behavior. What is happening inside the application is opaque - perhaps run with procmon to see what is going on?
Either way, this is going to require that you build SPM from source to debug this, I don't think that you are going to make any headway otherwise.
procmon reports, as already reported by me, many buffer overflows (see begin of this topic).
The Package Manager on GitHub - apple/swift-package-manager: The Package Manager for the Swift Programming Language is a Swift package itself, so I cannot build it without SPM working, right?
And as I stated before, all of them are irrelevant. Those are not from the SPM side of things. Something else is causing that.
You can build SPM with CMake :).
I now tried, cmake Sources gives errors:
CMake Error at Basics/CMakeLists.txt:31 (set_target_properties):
set_target_properties called with incorrect number of arguments.
...
Your invocation is incorrect ;-)
Please refer to the instructions for building on Windows.
OK; where are those instructions?
Q: How do I get libcurl-development, libxml2-development, sqlite-3.28.0, zlib-1.2.11 in the form needed? It is not explained there. Thanks.
You would need to build them from source. You could grab a copy from the azure builders if you like. The sources for most of them is mirrored on github, SQLite is the only one which doesn't.
Already could not build libxml2 (I know I built that one once, but now...). So please where can I get this stuff from the Azure builders? Thanks.
(update: now checked-out the 5.4.3-RELEASE tags and set CMAKE_BUILD_TYPE=Debug)
Unfortunately I got a compile with /bigobj error when building, see end of this comment.
Update: see that fix for SR-14111. I got those errors again and again in different modules in llvm, and building take very very long, and every time it starts at the beginning, so question: Can I set /bigob globally? If not, how can I know wher to add if(MSVC) target_compile_options(module PRIVATE /bigobj) endif() with module replace by what? Sorry, all new to new.
FAILED: tools/clang/tools/extra/clang-tidy/modernize/CMakeFiles/obj.clangTidyModernizeModule.dir/LoopConvertCheck.cpp.obj
C:\PROGRA~2\MICROS~2\2019\COMMUN~1\VC\Tools\MSVC\1429~1.301\bin\Hostx64\x64\cl.exe /nologo /TP -DGTEST_HAS_RTTI=0 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_GNU_SOURCE -D_HAS_EXCEPTIONS=0 -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools\clang\tools\extra\clang-tidy\modernize -IS:\llvm-project\clang-tools-extra\clang-tidy\modernize -IS:\llvm-project\clang\include -Itools\clang\include -Iinclude -IS:\llvm-project\llvm\include /DWIN32 /D_WINDOWS /Zc:inline /Zc:strictStrings /Oi /Zc:rvalueCast /W4 -wd4141 -wd4146 -wd4244 -wd4267 -wd4291 -wd4351 -wd4456 -wd4457 -wd4458 -wd4459 -wd4503 -wd4624 -wd4722 -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 -wd4510 -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703 -wd4389 -wd4611 -wd4805 -wd4204 -wd4577 -wd4091 -wd4592 -wd4319 -wd4709 -wd4324 -w14062 -we4238 /MDd /Zi /Ob0 /Od /RTC1 /EHs-c- /GR- -std:c++14 /showIncludes /Fotools\clang\tools\extra\clang-tidy\modernize\CMakeFiles\obj.clangTidyModernizeModule.dir\LoopConvertCheck.cpp.obj /Fdtools\clang\tools\extra\clang-tidy\modernize\CMakeFiles\obj.clangTidyModernizeModule.dir\ /FS -c S:\llvm-project\clang-tools-extra\clang-tidy\modernize\LoopConvertCheck.cpp
S:\llvm-project\clang-tools-extra\clang-tidy\modernize\LoopConvertCheck.cpp : fatal error C1128: number of sections exceeded object file format limit: compile with /bigobj
[3169/6194] Building CXX object tools\clang\tools\extra\cl...j.clangTidyModernizeModule.dir\ModernizeTidyModule.cpp.obj
ninja: build stopped: subcommand failed.
This is strange. Other than that the error is wrong, my understanding is that if your toolchain version is 5.4.2, then the error message should suggest that you prepend "// swift-tools-version:5.4.2" instead of "5.4.0". Because the message just uses whatever SwiftPM thinks your current toolchain version is.
Not sure how relevant my comment here is to the problem, though.
With the things in ticket SR-15125 of what should be added on the Getting Started page, that problem does not persist.
Right now I have the following problem:
- SPM gets stuck with a message like
C:\Users\stefan\AppData\Local\Temp\TemporaryDirectory.eK9Mr0\swiftxml-manifest.exe -handle 414 - To further examine this, I should build Swift in debug mode, but I get several
compile with /bigobjerrors, I do not know how to set this globally, starting the build process again and again and to see where it stops takes very very long time.
I'm not sure that you need to build all of Swift for just SPM. You already have a working compiler, and should have the corelibs. You should be able to get away with just building t-s-c, llbuild, Yams, swift-driver, swift-crypto, and swift-package-manager.
-D CMAKE_C_FLAGS="/bigobj" -D CMAKE_CXX_FLAGS="/bigobj" should set the flags globally. I recommend that you checkout CMake Tutorial โ CMake 3.24.2 Documentation
1 Like