Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
xcopy - Invalid number of parameters (Qt 5.15.2)
_2020_ last edited by _2020_
I am following the instructions to build Qt for Android (Qt 5.15.2) on a Windows 10 PC (see https://doc.qt.io/qt-5/android-building.html).
I configured the project successfully and ran "mingw32-make" to build the project. After about 6 hours of building, it failed with the following initial error message:
mingw32-make: Entering directory 'F:/Qt/18.104.22.168_jva/qtbase/src/android/java' C:\Android\sdk\ndk\22.0.7026061/toolchains/llvm/prebuilt/windows-x86_64/bin/clang++ -target aarch64-linux-android21 -fno-limit-debug-info -Wl,--enable-new-dtags -Wl,--build-id=sha1 -Wl,--no-undefined -Wl,-z,noexecstack -shared -o java -llog -lz -lm -ldl -lc xcopy /s /q /y /i F:\Qt\5.15.2_jva_src\5.15.2\Src\qtbase\src\android\java\res F:\Qt\22.214.171.124_jva\qtbase\src\android\java Invalid number of parameters mingw32-make: *** [Makefile:105: java] Error 4 mingw32-make: Leaving directory 'F:/Qt/126.96.36.199_jva/qtbase/src/android/java' mingw32-make: *** [Makefile:92: sub-java-make_first-ordered] Error 2 mingw32-make: Leaving directory 'F:/Qt/188.8.131.52_jva/qtbase/src/android' mingw32-make: *** [Makefile:828: sub-F--Qt-5-15-2_jva_src-5-15-2-Src-qtbase-src-android-make_first] Error 2 mingw32-make: Leaving directory 'F:/Qt/184.108.40.206_jva/qtbase/src' mingw32-make: *** [Makefile:51: sub-src-make_first] Error 2 mingw32-make: Leaving directory 'F:/Qt/220.127.116.11_jva/qtbase' mingw32-make: *** [Makefile:88: module-qtbase-make_first] Error 2
Here is a screenshot:
I tried running the xcopy command manually from cmd prompt and it worked ("21 Files(s) copied"), so unsure why it is failing for the Qt compilation process?
I located the makefile with the offending line, but am unsure exactly what the problem might be. Perhaps one of the two xcopy lines needs to be removed? Remove the extra space in the second line? Something else?
I will be trying each possibility until I get something working, but it takes up to 6 hours every time, hence this shot in the dark post looking for help.
Any help is most appreciated. Thanks!
JonB last edited by JonB
I happen to be interested in this sort of question... :)
The bad news is that there is nothing wrong with that command --- and believe me I have looked very carefully, checking needs for quoting/backslashes/forward slashes.. That's why it works when you do it yourself directly....
The good news is that I bet you $0.02 your situation is described at xcopy doesn't work when in a makefile ! Look very closely at the second comment there:
mingw32-make has the nasty habit of running commands through sh instead of cmd if it can find sh.exe in PATH. Make sure that you don't have it added by cygwin or by git (if you chose the complete unix utility folder to be added to PATH during installation).
And sure enough, you are using
Quite what you are going to do about it here to get your make to run through though I'm not sure. Can you afford to temporarily rename the
shit is using (
where shshould tell you) to something else, or remove its directory from
PATH, without breaking other things? If not: you could try putting
cmd /c(or maybe
cmd.exe /c) at the start of each of the
cmd /c xcopy /s /q /y /i F:\Qt\5.15.2_jva_src\5.15.2\Src\qtbase\src\android\java\res F:\Qt\18.104.22.168_jva\qtbase\src\android\java
That might be enough to make it not use
shand so work??
@JonB Thank you for the response! Your info initially seemed promising, however, running "where sh" in command prompt yields the following:
INFO: Could not find files for the given pattern(s).
Same result for running "where bash".
I also have realized that Qt creates the makefile (as well as its parent directory) automatically during the build process before running it, so I am unaware of a way in which I could make changes to the file and then have Qt run that. If I can maybe locate the code which creates the Makefile itself, then I could change that?
I will see if I can locate it...
I guess a more general question in my mind is how was Qt for Android 5.15.2 built for the official Qt Windows release? Presumably on a Windows machine? Maybe with a different compiler? The official 5.15.2 Qt for Android runs on my PC just fine, but there is a known bug in it which causes a runtime error on my mobile device. To fix the bug I am trying to build Qt for Android itself from source.
JonB last edited by
Your info initially seemed promising, however
That would be sad for me, as I would lose the $0.02 which I risked on this and felt pretty confident about.
Make sure that you don't have it added by cygwin or by git ( [...]
You don't have either of these installed perchance?
@JonB I actually did have Git installed (but not Cygwin), so I uninstalled it.
I also did a complete search of all my drives for "sh.exe." as well as "bash.exe", and renamed them to be "sh2.exe" and "bash2.exe" for the time being. ( I got this idea partially from you and partially from here: https://web.stanford.edu/class/archive/cs/cs106b/cs106b.1184/qt-creator-troubleshooting.shtml). Three copies of "bash.exe" would not allow rename or deletion, however, even with admin privileges ("You require permission from SYSTEM to make changes to these files"). These were located here: C:\Windows\WinSxS\amd64_microsoft-windows-lxss-bash_31bf3856ad364e35_10.0.19041.423_none_1da742a41b53e164.
I removed all Qt files from previous build attempts. Re-downloaded the source code. I ran the configure command to prep the source for building. Then ran "mingw-make" again in the appropriate folder. 6 hours later: same error message as before:
I have not been able to locate how/where the "xcopy" Makefile is created in the Qt source code but will keep looking for something. I may also try to force a rename on those 3 stubborn bash.exe files. And go through my PATH variable with a fine-toothed comb.
Thanks for the help. Any further tips are most appreciated!
JonB last edited by JonB
I have not been able to locate how/where the "xcopy" Makefile is created in the Qt source code
Personally I have never built Qt, so I can't be exact. But somewhere when you first "configure" for your system, or "configure"
qmake, I think there is a like a
.conffile and that will contain the
xcopycommand you see (e.g. if you were configuring for Linux it would not be
xcopy). When you find that file that's where the command comes from.
However, as I say, the
xcopybeing issues does actually look perfectly fine. As you have discovered by copying the line from the terminal and executing it. So I don't know what you think you are going to change it to that will work anyway?
Even though we haven't tracked it down, that article about it being a shell issue fits the bill just perfectly. And the fact that you are MinGW 32-bit.
xcopycommand, I came across https://forum.qt.io/topic/112574/qmake_copy_dir-on-windows-uses-cp-over-xcopy-if-found-on-path
Building for Windows 10 I would expect QMAKE_COPY_DIR to use 'xcopy /s /q /y /i' as defined in mkspecs, ...
mkspecs. If you know what that is to do with building Qt/
qmake, that's what you'll need to track down.
QMAKE_COPY - performs file copying, and on different platforms it transforms into xcopy, or cp, or else.
And this: https://wiki.qt.io/Undocumented_QMake
So there are some leads for you....
@JonB Thanks for your help again. I do not know exactly why the xcopy command is failing when in the Makefile, and so I guess I do not know what changes to try to make to the command. I thought I might try to add "SHELL=cmd" to the top of the Makefile based on a post I read, but cmd does not actually recognize that command.
I tried stripping down my PATH variable to be absolutely bare-bones minimum to build Qt - still failed.
I think I am done with Qt. The bug fix to the original problem in my project actually exists in 5.15.3, but that is for commercial customers only (open source, yeah right!). Time to start completely over in Android Studio I guess.
koahnig last edited by
Why are you building Qt for Android anyhow?
I am using the pre-built Android versions on Win 10 64 bit. The only thing you have to careful is the use of the correct NDK, which is not always the latest one.