I am trying to deploy my project(built with Qt Creator) into a single, static executable(Windows). I am having trouble doing this, even though I feel like I am following the Qt tutorial exactly.
The tutorial I am following: http://qt-project.org/doc/qt-4.8/deployment-windows.html
First, I open the Qt Command Promt, and enter 'configure -static'.
Just to ensure I am doing EVERYTHING correct, I am even showing the command prompt I am using.
I go through the 'configure' steps, and this is my output.
After entering the 'configure -static' command, I get this as the output. (put on Pastie to keep this clean).
http://pastie.org/3580144
I then enter 'nmake sub-src', and get this as the output:
C:\Qt\4.8.0>nmake sub-src
Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
cd ..\..\src\tools\bootstrap\ && c:\Qt\4.8.0\bin\qmake.exe \src\tools\bootstrap\bootstrap.pro -o Makefile
Cannot find file: \src\tools\bootstrap\bootstrap.pro.
NMAKE : fatal error U1077: 'cd' : return code '0x2' Stop.
C:\Qt\4.8.0>
I get this same output even if I just command 'nmake'. I have the Qt SDK installed, and I have no idea what to do at this point as I've Googled everything. Thanks for any help, Hetelek.
It's that leading slash on the file path - it makes the file path "absolute." SO nmake is looking for the file:
C:\src\tools\bootstrap\bootstrap.pro
but your file is actually saved as:
C:\Qt\4.8.0\src\tools\bootstrap\bootstrap.pro
Now, I'm not sure how to configure nmake to use the right path, but that's your problem right there. And if all else fails, you can always move your src folder to the root of your C drive so it's where nmake expects it to be.
Hope that helps!
Related
I need to link GDAL library to a c++ project.
I use the instruction from here:
http://trac.osgeo.org/gdal/wiki/GeneratingVisualStudioProject
Download gdal231.zip from official web site. Unpack.
(this step may be omitted — result will be the same) Edit nmake.opt by adding this in the very top of the file:
MSVC_VER=1910
WIN64=1
(don't know if it's right; there is no thorough guide)
Run win cmd, type "generate_vcxproj.bat 15.0 64 gdal_vs2017", wait for finish.
Open gdal_vs2017.vcxproj with MSVS Community 15.8.4. Build solution.
Build failed with "fatal error C1083: Cannot open include file: 'stdio.h': No such file or directory".
Project settings look strange:
1
"VC++ Directories" seem normal, except $(VC_SourcePath) in "Library Directories":
2
What's wrong with it?
In order to build GDAL one doesn't need a Visual Studio project. Don't know what's wrong with "generate_vcxproj" script — it just does'nt work. But there is another way.
Unpack gdal231.zip.
Launch "x64 Native Tools Command Prompt for VS 2017" (or whatever version of VS command prompt that suits your needs). cd to "gdal-2.3.1\" dir.
Open nmake.opt file. In it's beginning there are some hints for usage of makefile.vc. Pick some arguments from there. I opt for x64 release build, so my call to nmake was like that: "nmake -f makefile.vc MSVC_VER=1910 WIN64=1". (1910 is a version of Visual Studio 2017).
Switch to "Native tools command prompt" and type "nmake -f makefile.vc MSVC_VER=1910 WIN64=1" there. Enter.
When it's finished, type "nmake -f makefile.vc MSVC_VER=1910 WIN64=1 install" and press Enter.
When that's finished too, type "nmake -f makefile.vc MSVC_VER=1910 WIN64=1 devinstall" and press Enter.
Done. The library is in C:\warmerda\bld\ folder.
I got the same problem when building with VS2017 Community Edition. I was able to build fine using VS2015 Community Edition.
Bottom line: when running the .bat, use the 2015 option.
Modify the generate_vcxproj.bat file using the information from here:
https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#Internal_version_numbering
I modified mine to work with Visual Studio Community 2019 by modifying lines 55-70 to be this:
if "%_vcver_%"=="16.2" (
set _clver_=1922
set _vstoolset_=v1422
) else if "%_vcver_%"=="15.0" (
set _clver_=1910
set _vstoolset_=v141
) else if "%_vcver_%"=="14.0" (
set _clver_=1900
set _vstoolset_=v140
) else ( if "%_vcver_%"=="12.0" (
set _clver_=1800
set _vstoolset_=v120
) else (
echo Wrong value for parameter 1. See usage:
goto :usage
))
I'm following this guide on building V8 but I am hitting some issues on the compilation step. I am running Windows 10 x64. I am trying to compile with options to embed the engine also.
Running the following command:
ninja -C out.gn/x64.release
Gives me this error:
ninja: Entering directory `out.gn/x64.release'
[1/471] LINK mksnapshot.exe mksnapshot.exe.pdb
FAILED: mksnapshot.exe mksnapshot.exe.pdb
C:/Workspace/depot_tools/win_tools-2_7_6_bin/python/bin/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 False link.exe /nologo /OUT:./mksnapshot.exe /PDB:./mksnapshot.exe.pdb #./mksnapshot.exe.rsp
LINK : fatal error LNK1181: cannot open input file 'comdlg32.lib'
ninja: build stopped: subcommand failed.
Now I believe I have narrowed down the error to looking for the .lib files in the wrong directory. I have (had) multiple versions installed, so there were multiple folders in my Windows Kit install.
Windows Kits/10/Lib/10.0.16299.0
Windows Kits/10/Lib/10.0.15xxx.0
If I dragged and dropped the comdlg32.lib file from 10.0.16299.0 into the 10.0.15xxx.0 directory then the error changed to a LNK1181 error with a different input file. I did this a few times but I was unsure if this was going to cause issues with different versions and there was probably going to be a lot.
I uninstalled the 10.0.15xxx.0 version which left behind the folder I mentioned, so I removed that and after doing so I have started getting the LNK1181 error with a different input file (advapi32.lib I assume the very first file it can't find). This is how I came to the conclusion about the path being incorrect.
So I have tried a few things to change the path (I hoped just uninstalling the old version would fix it) such as:
Uninstalling the old version.
Going through registry entries to see if I can find an install path or something using that path, which I didn't. I did notice that there was still installation and data in the registry for the 10.0.15xxx.0 install, I might try deleting that from the registry directly as a last resort?
I have tried to explicitly set the path by setting <TargetUniversalCRTVersion>10.0.16299.0</TargetUniversalCRTVersion> in this file: C:\Program Files (x86)\Windows Kits\10\DesignTime\CommonConfiguration\Neutral\uCRT.props
I have never used Ninja before so I tried looking for a way to set some kind of lib-path in the command but couldn't really find anything.
I looked through the python scripts being executed to try and locate something to do with the libs path but couldn't see anything.
I would be grateful for any help and suggestions. Thanks.
You can try to compile v8 using Visual Studio as explained here: https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#using-the-visual-studio-ide
By running the following commands:
$ gn gen --ide=vs out.gn/x64.release
$ cd out.gn/x64.release
$ msbuild all.sln
You can see a full example here: https://github.com/phpv8/v8js/issues/272#issuecomment-262848754
Apparently this method is not officially supported anymore, but I had the same problem as you have and this solved the issue for me.
Note that after this I had another issue, the unit tests failed to be compiled due to a linking error, but I had the necessary libraries to use v8. So there may be deeper problem that is causing all of this that I'm missing.
Edit:
Also, you could try to set the following parameters with gn args:
visual_studio_path = "..."
visual_studio_version = "2017"
wdk_path = "..."
windows_sdk_path = "C:\Program Files (x86)\Windows Kits\10"
To set those parameters, do:
gn args out.gn/x64.release
This will open a text editor where you can write the extra parameters you are interested in.
To see the full list of parameters you can specify:
gn args --list out.gn/x64.release
I was following this guide https://medium.com/dailyjs/how-to-build-v8-on-windows-and-not-go-mad-6347c69aacd4 and also ran into the error
LINK1181: cannot open input file 'advapi32.lib'
I'm pretty sure it was because I had the wrong versions of the Windows 10 SDK. Similar to you I had versions:
Windows Kits/10/Lib/10.0.10240.0
Windows Kits/10/Lib/10.0.16299.0
But according to https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#Setting-up-Windows (Which I think is relevant) you need version 10.0.15063.0
After installing version 10.0.15063.0 (with the visual studio installer) to
Windows Kits/10/Lib/10.0.15063.0
I was able to continue with the build.
I have been following the instructions in the OpenSSL User Guide, which links to a guide by 3noch for compiling OpenSSL. Here are the tools/versions I am using:
ActiveState Perl v5.20.2
Microsoft Visual Studio 2012
Netwide Assembler (NASM) v2.12.02
OpenSSL 1.0.2j (source tarball)
Following the instructions, I am able to execute the following commands without issue:
perl Configure VC-WIN32 --prefix=C:\Build-OpenSSL-VC-32
ms\do_ms
Then, when I go on to execute
nmake -f ms\nt.mak
I receive the following
Assembling: tmp32\sha1-586.asm
tmp32\sha1-586.asm(1432) : error A2070:invalid instruction operands
tmp32\sha1-586.asm(1576) : error A2070:invalid instruction operands
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0
\VC\BIN\ml.EXE"' : return code '0x1'
Stop.
After looking into that issue, I found a blog post by HostageBrain that mentions that exact error, stating to use nasm to perform the compiling. So, I switched to this command sequence:
perl Configure VC-WIN32 --prefix=C:\Build-OpenSSL-VC-32
ms\do_nasm
nmake -f ms\nt.mak
However, once switching to the NASM variation, I receive the following errors:
tmp32\sha1-586.asm:1: error: parser: instruction expected
tmp32\sha1-586.asm:2: error: parser: instruction expected
tmp32\sha1-586.asm:3: error: parser: instruction expected
tmp32\sha1-586.asm:4: warning: label alone on a line without a colon might be in error
tmp32\sha1-586.asm:5: warning: label alone on a line without a colon might be in error
tmp32\sha1-586.asm:6: warning: label alone on a line without a colon might be in error
tmp32\sha1-586.asm:7: error: symbol `IF' redefined
tmp32\sha1-586.asm:7: error: parser: instruction expected
tmp32\sha1-586.asm:8: error: parser: instruction expected
tmp32\sha1-586.asm:9: error: comma expected after operand 1
What I am looking for is to be able to compile OpenSSL into .lib files that I can then link to from other C++ projects, such as when compiling FreeTDS.
On the same my blog page which you refer I also describe 'no-asm' case - this case is simpler for compiling (it won't require nasm at all), but drawback is - some algorithms performance will be 2x-4x slower than assembler versions.
If your case can accept this performance - try to compile 'no-asm' case.
perl Configure VC-WIN32 no-asm --prefix=C:\Build-OpenSSL-VC-32
I built the library from a regular command prompt on Windows 10 with VS 2015 with the following commands (debug build shown):
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\vcvars64.bat"
perl Configure debug-VC-WIN64A --prefix=C:\Path\to\target\folder
ms\do_win64a
nmake -f ms\ntdll.mak
cd out32dll.dbg
..\ms\test
cd ..
nmake -f ms\ntdll.mak install
I know this is an old post, but for others having the problem with NASM parsing errors, here's the solution:
Once you run either ms\do_ms.bat (to use masm) or ms\do_nasm.bat (to use nasm), you can't just switch to the other one without first clearing out the tmp32 directory, otherwise perl will never regenerate the .asm files correctly. The parser errors you're getting are from nasm trying to assemble a masm-formatted file.
The easiest way to clean out tmp32 is to run "nmake -f ms\nt.mak clean".
Answering to this very old question. There are a couple of problems associated with building it under x64 that way including hitting "assemblers not found", downloading NASM and adding to path etc. There is a very good and simple solution using MSYS2.
Install MSYS2. Ensure you get the toolchain needed (see the guide for pacman). Then follow below steps
$Launch msys2_shell.cmd -mingw64
$wget -c ftp://ftp.pca.dfn.de/pub/tools/net/openssl/source/openssl-1.0.2o.tar.gz
$tar -xzvf openssl-1.0.2o.tar.gz openssl-1.0.2o/
$cd openssl-1.0.2o/
$./configure shared mingw64
$make
That's it. In apps directory you will get openssl executable along with the libraries.
-Sreejith. D. Menon
Its kinda an odd story. I'm trying to build the openssl library. Well, it is not the first time I'm doing it and until now it was fine. however, I've desided to add a build configuration to TeamCity (actually the problem has nothing to do with TeamCity)to build all my third parties libraries on-demand. So, I created a step with common set of openssl build commands:
perl Configure VC-WIN64A
ms\do_win64a.bat
nmake /d /f ms\ntdll.mak
... and the build failed while assembling the very first asm file. So I ran same commands in VS2012 x64 command prompt and the build succedeed, as expected. It took a while untill I figured out that the problem is in output redirection. Teamcity redirects output from build step to the teamcity build log, so did I by adding ">1.txt" to "nmake /d /f ms\ntdll.mak" command, and the build failed. I would say it is somewhat unexpected reason for build to fail.
So far, I've tried:
Building the same from VS2010 command prompt with redirection,
failed.
Building the same from VS2010 command prompt without
redirection, succeded.
Building the same from VS2010/VS2012 command
prompt with redirection to file and forcing redirection to CON (nmake
/d /f ms\ntdll.mak >CON >1.txt) failed.
Googling for "nmake problems
when console output is redirected" - nothing
Googling for "openssl
build problems when console output is redirected" - nothing
My setup
- Win2008R2, virtual machine.
- VS2010, latest updates
- VS2012, Update 1
Actual error:
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN\amd64\ml64.EXE"' : return code '0x1'
ml64.exe complains about the asm file stating it should end with "END" statement. It does, but...
Any ideas?
Ok, since the problem is in perl and writing files to stdout and then redirecting it you have to change following files to build x64 version:
crypto\aes\asm\aes-x86_64.pl
crypto\bn\asm\modexp512-x86_64.pl
crypto\bn\asm\x86_64-gf2m.pl
crypto\bn\asm\x86_64-mont.pl
crypto\bn\asm\x86_64-mont5.pl
crypto\md5\asm\md5-x86_64.pl
crypto\modes\asm\ghash-x86_64.pl
crypto\rc4\asm\rc4-md5-x86_64.pl
crypto\rc4\asm\rc4-x86_64.pl
crypto\sha\asm\sha1-x86_64.pl
crypto\sha\asm\sha512-x86_64.pl
crypto\whrlpool\asm\wp-x86_64.pl
crypto\x86_64cpuid.pl
engines\asm\e_padlock-x86_64.pl
you have to open these files and change all "open STDOUT "whateverfile"" to something like "open my $asmfile "whaeverfile"", then take care of string concatenation (only in x86_64cpuid.pl) and then print it to the file instead of STDOUT, something like "print $code" to "print $asm $code"
and of course, dont forget to close the file, in another words change the "close STDOUT" to "close $asmfile"
Obviously when building target other than x64 one will have to change another set of files.
Will try to communicate it to openssl maintainer.
Edit 2 -
I don't have the application file qmake in the /bin folder and this is the error I am getting.
Path environment variable : C:\development\referencebuilds\qt\4.7.4\qt-everywhere-opensource-src-4.7.4\bin\
Command Prompt - visual studio 2005
Source folder - C:\development\referencebuilds\qt\4.7.4\qt-everywhere-opensource-src-4.7.4
Steps -
Downloaded src
Extracted the files to folder – qt-everywhere-opensource-src-4.7.4(C:\development\referencebuilds\qt\4.7.4)
configure.exe -opensource -fast -no-accessibility -no-qt3support -no-multimedia -no-audio-backend -no-phonon -no-phonon-backend -no-webkit -no-scripttools -platform win32-msvc2005 -D “_BIND_TO_CURRENT_VCLIBS_VERSION=1”
4.nmake
The error I get is
Microsoft (R) Program Maintenance Utility Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
C:\development\referencebuilds\qt\4.7.4\qt-everywhere-opensource-src-4.7
.4\bin\qmake C:/development/referencebuilds/qt/4.7.4/qt-everywhere-opensource-sr
c-4.7.4/\projects.pro -o Makefile -spec win32-msvc2005
'C:\development\referencebuilds\qt\4.7.4\qt-everywhere-opensource-src-4.7.4\bin\
qmake' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: 'C:\development\referencebuilds\qt\4.7.4\qt-everywher
e-opensource-src-4.7.4\bin\qmake' : return code '0x1'
Stop.
I know I dont have the app files for qmake and many other appfiles in my \bin folder. How do I get them?
Edit 1
Well, after trying out all the answers, the situation still remains the same. I think i should add more details to what I am doing.
I am copying bin files(.dll , Appplication, Application Extension, Incremental Linker File, Program Debug Database, ) from another machine and the version of Qt was 4.7.2
My questions are -
1. Do you see that as the cause for all the issues here? If yes, how do I get all the above files? If I just congigure as above and then run nmake I get
Microsoft (R) Program Maintenance Utility Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
C:\development\referencebuilds\qt\4.7.4\bin\qmake
C:/development/referen cebuilds/qt/4.7.4/\projects.pro -o Makefile
-spec win32-msvc2008
'C:\development\referencebuilds\qt\4.7.4\bin\qmake' is not recognized
as an inte rnal or external command, operable program or batch file.
NMAKE : fatal error U1077:
'C:\development\referencebuilds\qt\4.7.4\bin\qmake' : return code
'0x1' Stop.
1, Downloaded the source file named
qt-everywhere-opensource-4.7.4 and saved it in folder c:\development\referencebuilds\qt\4.7.4\
2, uncompressed the zip file and the files extracted into folder
c:\development\referencebuilds\qt\4.7.4\qt-everywhere-opensource-4.7.4
3, Copied back all files from the folder
c:\development\referencebuilds\qt\4.7.4\qt-everywhere-opensource-4.7.4 to c:\development\referencebuilds\qt\4.7.4\
4, ran
configure.exe -opensource -fast -no-acce ssibility -no-qt3support
-no-multimedia -no-audio-backend -no-phonon -no-phonon- backend
-no-webkit -no-scripttools -platform win32-msvc2008 -D
"_BIND_TO_CURRENT
_VCLIBS_VERSION=1"
5, nmake and now I get the following errors.
C:\development\referencebuilds\qt\4.7.4\bin\qmake
C:/development/referen cebuilds/qt/4.7.4/\projects.pro -o Makefile
-spec win32-msvc2008 Could not find mkspecs for your
QMAKESPEC(win32-msvc2008) after trying:
C:\Qt\4.7.2\mkspecs Error processing project file:
C:/development/referencebuilds/qt/4.7.4//projects .pro NMAKE : fatal
error U1077: 'C:\development\referencebuilds\qt\4.7.4\bin\qmake.EX E'
: return code '0x3' Stop.
I have no clue as to why it is refering to C:\Qt\4.7.2\mkspecs . How do I get over this error? what is exactly happening. How do I prevent such issues in future?
Your install directory is:
c:\development\referencebuilds\qt\4.7.4\qt-everywhere-opensource-4.7.4
Let's call it $(QTDIR). Now:
Extend your PATH variable to include $(QTDIR)\bin
Specify the QMAKESPEC environment variable to be win32-msvc2005
Open a Visual Studio command prompt to get the Visual Studio environment variables
Run configure
Run nmake
This procedure usually gets the Qt build to work for me.
Make sure that you don't have any existing QT directories in your path before you call configure and nmake.
It looks like you have a previous version of Qt installed. "C:\Qt\4.7.2\". And it would seem you have it setup in your system variables. Look for a variable called QTDIR in your system environment variables. Which is why you are getting an error, basically your 4.7.2 Qt is trying to build the new version.
Two options:
Un-install your old Qt via add/remove software in the control panel.
or
Remove your QTDIR system variable for the time being (will require a re-login) so that when you try to build from source it will use the correct binaries from the source folder.
Then just follow this guide:
http://en.wikibooks.org/wiki/Opticks_Developer_Guide/Getting_Started/Building_Qt_From_Source