I have 2 questions regarding NGINX:
Is there any one who had already compile NGINX with Visual Studio? I want create a VS9 Project for compiling NGINX.
It's my veritable need, is there any way to compile NGINX as Lib or DLL?
I just finished building a Visual Studio 2010 project for nginx. The process wasn't entirely straight-forward, so I will attempt to detail everything I've learned. This is a several-hour to several day process, depending on your experience.
Step 1: You must first follow the Guide for building nginx on windows. This not only builds nginx, but also creates .c and .h files that you will use when creating your Visual Studio project. It won't work without these files. (For more information, see here.)
If you are less experienced with Unix like me, the guide above leaves some unanswered questions. So I'll first flesh out that guide with tips of my own, and then later, tell you more about creating a project for Visual Studio.
Part I: Compiling nginx for windows using MSYS
First, follow all the steps given above. Install MSYS, Strawberry Perl, Mercurial, and download the PCRE, zlib, and OpenSSL libraries. Then follow these steps:
1) Open a command prompt As Administrator. Then run your Visual Studio vc\vcvarsall.bat file to set
your environment variables to use VC as the compiler. Your paths will be different, but the command I used was:
"C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"
I found that even though the Strawberry Perl added 3 paths (which you can verify by examining your PATH variable), it still was using the wrong Perl.
2) Launch MSys by running msys.bat. For me, MSys was installed inside of the MinGW directory, so my path was:
C:\MinGW\msys\1.0\msys.bat
If successful, you should see something like this in green:
JensenV#AVWMA047LB ~
(except with your username#networkaddress instead) in a window called something like MINGW32:~
You might be wondering where your 'home folder is. It's under msys\1.0\home. So on my system, it's here:
C:\MinGW\msys\1.0\home\JensenV
If you do "ls" or "dir" this is the directory you're in initially.
3) Assuming you installed Mercurial as instructed above, you should now be able to check out ngynx source:
hg clone http://hg.nginx.org/nginx
This will go into the directory mentioned above.
4) You need to make sure the version of perl being used is strawberry perl, NOT the version that comes with msys. Type:
which perl
If you get something like "/bin/perl.exe" that's the wrong perl and you need to fixing your paths. You can either mess with this (as I did, unsuccessfully) OR you can just disable the version of perl that comes with msys. I just renamed
perl.exe to perl_UNUSED.exe in my msys install:
C:\MinGW\msys\1.0\bin
Whatever you do, make sure "which perl" shows the path to Strawberry Perl before proceeding.
5) Also renamed "link.exe" in my msys\1.0\bin directory:
C:\MinGW\msys\1.0\bin
so that it's unused. (i.e. rename it to "link_UNUSED.exe")
I believe this is because, in Step 1 above, your "vcvarsall.bat" set everything to use Microsoft C's compiler/linker, but then in Step 2, the linker was changed to use the Msys one instead. You need to use the Microsoft one.
To verify renaming as "link_UNUSED.exe" was successful, type:
which link
and ensure it points to your Visual Studio 10 link, not the link.exe that came with msys.
6) First "cd nginx" then create an objs/lib folder tree inside of the nginx folder. Untar/unzip pcre, zlib, and openssl in here as mentioned in the guide.
7) While your current directory is still nginx, run nginx's autoconfigure script, but first modify the command below to change the paths for
sopenssl, pcre, and zlib to be correct for what you installed in objs/lib (your version numbers may be different). The command I used was:
auto/configure --with-cc=cl --builddir=objs --prefix= \
--conf-path=conf/nginx.conf --pid-path=logs/nginx.pid \
--http-log-path=logs/access.log --error-log-path=logs/error.log \
--sbin-path=nginx.exe --http-client-body-temp-path=temp/client_body_temp \
--http-proxy-temp-path=temp/proxy_temp \
--http-fastcgi-temp-path=temp/fastcgi_temp \
--with-cc-opt=-DFD_SETSIZE=1024 \
--with-pcre=objs/lib/pcre-8.33 \
--with-zlib=objs/lib/zlib-1.2.8 \
--with-openssl=objs/lib/openssl-1.0.1f \
--with-select_module --with-http_ssl_module --with-ipv6
If you want to change any configuration options, NOW IS THE TIME. These options affect the generated .c and .h files that you will use later in creating your Visual Studio project, and trust me, you don't want to have to redo that later when you realize you need different options.
7) Make it.
nmake -f objs/Makefile
If successful, your freshly compiled nginx.exe should be inside your home\YourUsername\nginx\objs folder. i.e. something like:
C:\MinGW\msys\1.0\home\JensenV\nginx\objs
In addition, these files will now be in the same folder as nginx.exe:
ngx_auto_config.h
ngx_auto_headers.h
ngx_modules.c
ngx_pch.c
You will use these in creating your Visual Studio project.
8) Have a beer.
**
Part II: Creating the Visual Studio nginx Project
**
Create an empty Visual Studio project for Command Line application. Save the project inside your nginx folder (root level). Note that before this step you can move your nginx folder outside of msys to wherever you want to keep it.
1) Go to Properties -> VC++ Directories and add these Include Directories:
$(MSBuildProjectDirectory)\src\core
$(MSBuildProjectDirectory)\src\event
$(MSBuildProjectDirectory)\src\event\modules
$(MSBuildProjectDirectory)\src\http
$(MSBuildProjectDirectory)\src\http\modules
$(MSBuildProjectDirectory)\src\http\modules\perl
$(MSBuildProjectDirectory)\src\mail
$(MSBuildProjectDirectory)\src\misc
$(MSBuildProjectDirectory)\src\mysql
$(MSBuildProjectDirectory)\src\os
$(MSBuildProjectDirectory)\objs
$(MSBuildProjectDirectory)\src\os\win32
$(MSBuildProjectDirectory)\objs\lib\openssl\ssl\include
$(MSBuildProjectDirectory)\objs\lib\zlib
$(MSBuildProjectDirectory)\objs\lib\pcre
NOTE: Before this step I went into objs/lib and removed the version numbers from the zlib, pcre, and ssl folders. Either you should do this to, OR you should modify the paths above to match your installed versions. I removed the version numbers so that I can update to newer versions of these libraries in the future without breaking my project.
Click on the "Macros >>" button and verify that the MSBuildProjectDirectory path is a path to your nginx folder.
2) Likewise add these paths to your Library Directories:
$(MSBuildProjectDirectory)\objs\lib\openssl\ssl\lib\
$(MSBuildProjectDirectory)\objs\lib\pcre\
$(MSBuildProjectDirectory)\objs\lib\zlib\
Again, modify these paths to include version numbers if your objs/lib folder's contents still have version numbers.
3) Change these Project Properties as follows:
C/C++
General: Set "Treat warnings as errors" to No (WX-)
Preprocessor: Add these Preprocessor Definitions:
WIN32
NGX_WIN32
NGX_MAIL_SSL
NO_SYS_TYPES_H
FD_SETSIZE=1024
Linker:
Input: Add the following to Additional Dependencies:
ws2_32.lib
pcre.lib
ssleay32.lib
libeay32.lib
crypt32.lib
zlib.lib
4) Close your Visual Studio solution. Open up the project file (ends in .vcxproj) with a good text editor, such as Notepad++. (Make a backup copy of it first, in case anything goes wrong.) Also open up nginx\objs\makefile with a text editor.
In the makefile, not too far from the top, you'll see a section that starts something like this:
objs/nginx.exe: objs/src/core/nginx.obj \
objs/src/core/ngx_log.obj \
objs/src/core/ngx_palloc.obj \
objs/src/core/ngx_array.obj \
....
objs/ngx_modules.obj \
objs/nginx.res \
objs/lib/pcre-8.33/pcre.lib \
objs/lib/zlib-1.2.8/zlib.lib
$(LINK) #<<
Likewise, in the Visual Studio file, if you've added any source code (add any files you want prior to this step, so you can see what I'm talking about) you'll see something like this:
Create a new document containing just the .obj files from the makefile. Use Search & Replace in a text editor to modify them to match the format of the Visual Studio project file instead (so ending in .c /> instead of with .obj \, and starting with
Also don't forget to change the forward slashes to backslashes. Don't include the zlib.lib or pcre.lib lines. I forget if you should include nginx.res. (Probably not.)
Once you're sure the format is right, save your Visual Studio project and try opening it. If all the files from the makefile show up in your project, you did it correctly.
5) Remember those special .c and .h files that nginx created when you built the exe? You want to add them to your project now, too. Add these guys:
ngx_modules.c
ngx_pch.c
6) Now you're ready to compile!
I've honestly probably forgotten something along the way, so you might still have some linker or compile errors to fix, but this should give you a good start!
NOTE: If you want to change which options are included in nginx, you'll have to do a new auto/configure in Part I above, a new nmake, and then include additional source code in you Visual Studio project, and use the newly generated ngx_modules.c and ngx_pch.c files in your Visual Studio project.
Related
I recently installed vs15 - preview (Stripped down version of visual studio 2015).
I am able to compile C/C++ sources from inside the IDE, but I am not able to compile with the command line interface cl.exe. It can't find the c stdlib headers. I tried to use vcvars32.bat to set the proper reg values but seemingly it cant find the "Common Tools Folder".
"ERROR: Cannot determine the location of the VS Common Tools folder."
The script uses the env. variable "%VS150COMNTOOLS%".
If I try to run "cd %VS150COMNTOOLS%" from the cmd line, it can't find the path, so this seems to be the main problem.
How can manually set %VS150COMNTOOLS% to the right path? how can I set the cmd linker settings manually (Without telling the cl.exe every time I call it)?
Okay, I solved it by adding the path to the include directories and lib directories to the env. variables as "INCLUDE", "LIB". It works now, whyever the script was not able to set those values properly. I am not fluent in reading .bat let away writing in, I assume the directory structure, which is different for the vs15 preview when compared to the full version, had not been adapted yet.
I am trying to statically build Qt using Visual Studio 2013
To do so, I'm following the instructions provided by the official website
1) ActivePerl 5.20 is downloaded, installed and added to the PATH.
2) The archive for qt-everywhere-enterprise-src-5.3.1 is downloaded and unzipped in C:\Qt\Entreprise_2
3) I open msvc 2013 command prompt, and change directory to: C:\Qt\Entreprise_2\qt-everywhere-enterprise-src-5.3.1
4) From here, I add 2 new elements to the path:
SET PATH=C:\Qt\Entreprise_2\qt-everywhere-enterprise-src-5.3.1\qtbase\bin;C:\Qt\Entreprise_2\qt-everywhere-enterprise-src-5.3.1\gnuwin32\bin;%PATH%
5) I define the QMAKESPEC in order to use msvc: SET QMAKESPEC=win32-msvc2013.
6) finally, I launch the compilation:
configure -commercial -nomake tests -nomake examples -debug -static
If I skip part 5), I instead receive the
I receive the answer:
"QMAKESPEC environment variable is set to "win32-msvc2013" which is not a supported platform"
If I skip step 6, I obtain instead:
"Unable to detect the platform from environment. Use -platform commandlineargument or set the QMAKESPEC environment variable and run configure again"
However, according to Qt support center:
1) "win32-msvc2013" is the correct QMAKESPEC to use with Visual Studio
2) If we use Visual Studio Command prompt (as I did) instead of the normal one, setting QMAKESPEC is optionnal anywey, as visual studio is supposed to set the correct parameters at the beginning
So, does anyone have any idea about how I could resolve these errors?
Incidentally does anyone knows what defines a Qmakespec as corresponding to a "supported platform"?
Had the same problem, first go look in the mkspecs folder (from the archive) and make sure your platform is there, might not be supported or look here:
http://doc.qt.io/QtSupportedPlatforms/index.html
If your platform is supported and you have it in your extracted mkspecs folder, then no clue what your problem is?!?
Apparently, a good part of the files inside the mkspec folder either failed to copy when I extracted the archive, or were destroyed afterward. Most likely the latter, as it would appears that every time I try to launch a compilation some source file are erased.
The solution I found is to recreate the source file from the archive before every compilation.
I have a freshly downloaded Visual Studio C++ 2010 Express and wxWidgets 2.9.1. The build folder under wx\build\msw has solution files for VC++ versions 6 through 9 (2008).
I tried to open the latest solution, wx_vc9.sln. It converted all the projects with a bunch of warnings. When I try to build every project gets the error:
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5):
error MSB6001: Invalid command line
switch for "cmd.exe". The path is not
of a legal form.
Trying to open the previous version of the solution, wx_vc8.sln, generates the same conversion warnings and the same build errors.
I Googled for some hints and found a suggestion to start with the .dsw file. I opened wx.dsw and it generated an error for each of the project files:
D:\3rdParty\wx\build\msw\wx_wxregex.dsp
: error : Project upgrade failed.
Finally in desperation I tried nmake /f makefile.vc and was greeted with yet another error:
NMAKE : fatal error U1077: 'cl' :
return code '0xc0000135'
Anybody have any hints? Thanks.
There are two ways of solving this, firstly if you update to a more recent version of the wxWidgets SVN trunk this is fixed (and so it will be fixed in 2.9.2 when it is released). If you don't want to work from trunk of wait for 2.9.2 then if you do a find and replace over all .vcxproj files and replace
>$(INTDIR) $(OUTDIR);%(AdditionalInputs)
with
>%(FullPath);%(AdditionalInputs)
it should then compile fine.
For future reference, trust me people, avoid all nonsense and start up your Visual Studio 2010 Command Prompt and navigate to [wxwidgets directory]\build\msw
Then compile using the makefile with the following command :
nmake -f makefile.vc BUILD=release MONOLITHIC=0 SHARED=0 UNICODE=1
Of course change the options as needed.
You will be saving a lot of trouble this way, this is the way I did.
The Key to Compilation using Visual C++ 2010 Express and wxWidgets 2.9.3 is to keep Pressing F7 Again-and-Again-and-again.... till you you get '0 Failed' Message below. Because many Projects have dependencies which are not satisfied immediately, so it is necessary to keep compiling with 'F7' till all are satisfied.
Download wxWidgets. I downloaded the .7-Zip File (only 12 MB ! ), and installed it at C:\wxWidgets The Structure should be like so that you see the following Folders like C:\wxWidgets\lib and C:\wxWidgets\build etc etc...
Basically the process should be to go to C:\wxWidgets\build\msw , and open wx_vc9 Solution File for VC-2008, and convert it to VC-2010 when asked. Then Choose 'DLL-Release Win32' on Top, and Press F7. Wait for Compilation to take place and see the Message. Then keep Pressing F7 again and again till you get '0 Failed' Message below. Then you would want to Compile 'DLL-Debug' Release in the same manner.
The compiled DLL Files can then be found at C:\wxWidgets\lib\vc_dll. Now, To Add vc_dll Folder to your PATH, Right-Click on My-Computer -> Properties -> Advanced System Settings -> Environment-Variables -> User-Variables. Search for 'Path' -> 'Edit', and then Just Append ;C:\wxWidgets\lib\vc_dll to the End.
This makes running your compiled Application easier, as your .EXE can now easily find DLLs.
When you are packaging, then you obviously need to bundle specific Release-DLL'S along.
Then you can compile the Samples located at C:\wxWidgets\samples.
I just go to individual Project Folder, like for e.g. C:\wxWidgets\samples\drawing, and Open drawing_vc9 Project, then Convert it as Prompted, and then hit F7 to create Release Version. Now if you go inside C:\wxWidgets\samples\drawing\vc_mswudll\ Folder, you have your 'drawing.exe' ready-to-be-run !
Have fun !
Use the wx.dsw, took me a while to finally get it but it'll build fine after that. I also suggest using one of the sample projects such as 'minimal' as the base and just fix all the config paths to match what you want to build (as manually setting up I encountered issues).
If you already used the wx_vc9 (like you said you did) you are probably best off just deleting all of wx and restarting with it and using wx.dsw like I said above.
I can't find any information on how to install Qt built on Windows.
In wiki article How to set up shadow builds on Mac and Linux there's description of -prefix option in configure script but this option is not available on Windows.
I know I can use Qt right from the build folder but it does not seem the right thing not to perform an install step. One problem with this approach is size; Qt's build folder takes about 4GB space whereas after installing using binary installer Qt takes about 1GB space. I guess the difference is due to temporary files created during building. I hope some install procedure would install (copy) only needed files leaving temporary files in the build folder.
As İsmail said there's no install step for Qt on Windows.
However one can try to approximate it by performing the following operations.
Cleaning
Run make clean in the build folder to remove all temporary files.
Moving
Copy build folder to the place where you want Qt "installed". Let's call it INSTALL_DIR.
Fixing paths hardcoded in the qmake.exe executable
Run qmake -query to see what paths are compiled (hardcoded) into qmake and
a. Fix paths containing the build folder by replacing it with the INSTALL_DIR using qmake -set (1).
or
b. Create a qt.conf file in the bin subfolder of the INSTALL_DIR specifing new Qt paths inside it.
Adding current directory to include path
In Qt's provided binary distributions, the pwd is included in the QMAKE_INCDIR and thus ends up in your projects include path as ".". This does not happen by default in a custom built Qt, so you have to add the following line to mkspecs/YOUR-PLATFORM-HERE/qmake.conf file:
QMAKE_INCDIR += "."
Fixing prl files
When you add a Qt component to a project file (such as CONFIG += uitools), Qt looks in %QTDIR%/lib/QtUiTools.prl to find the library dependencies of that component. These files will have the hard coded path of the directory in which Qt was configured and built. You have to replace that build directory with the one to which you moved Qt for all lib/*.prl files.
Making source available
If you made a shadow build (build made inside folder other than the one containg sources), headers in the include subfolder only forward to the original headers. For example; BUILD_DIR\include\QtCore\qabstractanimation.h looks like this
#include "SRC_DIR/src/corelib/animation/qabstractanimation.h"
If you don't want to depend on the existence of the folder containg sources you have to copy SRC_DIR/src subfolder to your destination folder and fix all headers in the include folder so that they forward to the new location of src subfolder.
The bottom line:
The build process of Qt under Windows makes it really akward to move (install) Qt after building. You should do this only if ... well I can't find any good reason to go through all this trouble.
Remember
The easy way is to place Qt's sources in the folder where you want Qt to stay after building and make a build in this folder. This makes all steps but 1 and 4 above unnecessary.
1)
The variables you set with qmake -set are saved in the registry key
HKEY_CURRENT_USER\Software\Trolltech\QMake\<QMAKE_VERSION>.
Because of this you might have a problem when you would like to have different projects using different versions of Qt which happen to have the same version of qmake. In this case the better solution is to use qt.conf file (actually files as you need one file for each Qt installation) (option 3b).
Many of the information above come from the RelocationTricks wiki page authored by Gabe Rudy. Check out his Qt (Qt4) Opensource Windows Installers of Pre-built Binaries with MSVC 2008 project which gives you easy solution of above problems.
This answer is a replacement for steps 3 and 5 of Piotr's (currently top rated) answer above, but you may still need the other steps in his answer, depending what you're trying to achieve.
This is the operation which the official installer uses to fix the hardcoded paths during the installation: qt.520.win32_msvc2012.addons/meta/installscript.qs
This is how the operation is implemented: qtpatchoperation.cpp
This is the list of files that it fixes: files-to-patch-windows-qt5
And this shows how to invoke an installer operation as a standalone command from the commandline: Operations (Qt Installer Framework Manual)
To summarize: after moving your Qt directory to where you want it, download any one of the official Qt installers and run it with the following commandline arguments:
cd <path>
installer.exe --runoperation QtPatch windows <path> qt5
Replace <path> with the full path of your Qt directory after you moved it (the qtbase directory if you are using Qt 5). Omit the final qt5 argument if you are using Qt 4.
This will fix the hardcoded paths in qmake.exe, .prl files, and others. It gives you the exact same behaviour that the official installers have in that respect.
For the initial move, nmake "INSTALL_ROOT=\somewhere" install works for me. So that's steps 1 and 2 of Piotr's answer covered. And I haven't needed steps 4 or 6, FWIW.
I can configure QT 5 on WINDOWS (Visual Studio build) with the prefix option like:
configure -prefix C:\the\path\I\want ...
then call:
nmake
nmake install
and the latter will install Qt in C:\the\path\I\want.
I did it without problems with Qt 5.2.1 and 5.3.x, so far. So, any earlier problems seem to be fixed by now.
It's very odd people claim that there is no "make install" on Windows.
I have used it many times, and I agree that it's not what it is on other platforms, but it serves its purpose.
How I use Qt's make install on Windows (from cmd):
configure
(n/mingw32-)make
(n/mingw32-)make docs
(n/mingw32-)make install
The make install bit copies all necessary headers to be able to delete your source directory. Delete all objects and unecessary stuff:
del /S /Q *.obj lib\*.dll
rmdir /S /Q docs-build qmake tools src
This allows you to remove the source directory. I don't know what impact this has on debugging Qt source code, but it sure reduces the size of a shadow build. I use it to maintain 32 and 64 bit builds with minimal size.
Qt on Windows is not installable with make install, you will notice that Qt installer for Windows just patches dlls & pdbs for the new install location.
What I would suggest is to do a shadow build in the place you would like to install it. You can manually remove *.obj files to save up space.
Qt's own build instructions show how this is done, by search/replace within each Makefile. Assuming the source was extracted to C:\qt-4.8.3 and build was performed within that directory, then do this:
fart -c -i -r Makefile* $(INSTALL_ROOT)\qt-4.8.3 $(INSTALL_ROOT)\my-install-dir
set INSTALL_ROOT=
mingw32-make install
Then create a config file that tells qmake about its new installation path. Create a textfile C:\my-install-dir\bin\qt.conf:
[Paths]
Prefix=C:/my-install-dir
Translations = translations
Then as a final step (as Randy kindly pointed out) you need to patch qmake.exe, which can be done using a simple utility called QtMove. This same tool also automatically updates all the prl files.
Step 1: Move Qt
Cut and Paste
Current directory - C:\tools\Qt
Destination directory -C:\sim\dep\Qt
Step 2: Get Old Qt Directory
Go to C:\sim\dep\Qt\2010.02.1\Qt
Open .qmake.cache
Find variable QT_SOURCE_TREE
Note the value of QT_SOURCE_TREE
Mine was C:\tools\Qt\2010.02.1\Qt
Step 3: Patch Qt
Go to C:\sim\dep\Qt\2010.02.1\bin
The syntax is qpatch.exe list oldDir newDir
qpatch.exe files-to-patch-windows C:\tools\Qt\2010.02.1\Qt C:\sim\dep\Qt\2010.02.1\Qt
Step 4: Set Environment Variables
set QTDIR=C:\sim\dep\Qt\2010.02.1\Qt
set QMAKESPEC=C:\sim\dep\Qt\2010.02.1\Qt\mkspecs\win32-g++
set PATH=%path%;C:\sim\dep\Qt\2010.02.1\Qt\bin
set PATH=%path%;C:\sim\dep\Qt\2010.02.1\bin
You can do all of this with a batch file. This took me a fair while to work out and it has saved me a lot of time since. It's a script to automatically update a Qt installation to new locations. The batch file is available here.
There is a simple utility QtMove (http://www.runfastsoft.com) can do this easily.
Runs the relocated qmake.exe build your .pro file and everything should be linked with new Qt libs.
ok, so I ran into problems with Boost under visual studio 2010, so I decided to rebuild it with bjam: such as:
bjam --toolset=msvc-10.0 --build-type=complete
After running bjam (successfully?) it created a new directory under boost_1_42_0 called: bin.v2
Inside bin.v2 is directory called: libs.
Two issues:
1. there's lot less libs under that new directory (about 13), the old directory libs has 88. Is it supposed to be like that or did something fail?
2. the structure is somewhat different too.
What do I do with this exactly? Meaning, do I copy it over to the original libs, delete the old libs, try rebulding it with different flags?
First, as the message printed at the start of the build say, the libraries will be placed to stage\lib. The content of the bin.v2 directory should not matter. Also, I don't think any release of Boost ever put any libraries under bin.v2\libs directly. I recommend you just use stage\lib. You can look at messages to see if anything has failed to build. Also,
you probably want to try 1.43 beta for best results with VS10.