Currently, I'm trying to figure out how to set up SDL with MinGW. I've seen a couple of sites that have methods (or rather, the same method re-published), but I'd rather not have a "quick 'n dirty" setup.
I see there's an sdl-conf file, I have MSYS installed, and I've downloaded the latest SDL 1.2 MinGW developer release.
The tutorial is here. It explains everything needed:
First thing you need to do is download SDL headers and binaries.
You will find them on the SDL website, specifically on this page.
Scroll Down to the Development Libraries section and download the Mingw32 development library
Open gz archive and there should be a *.tar archive inside.
Open the *.tar and there should be a folder inside of that.
Open the folder and it'll contain a bunch of subfolders.
Copy the contents of the lib subfolder to the MinGW lib folder.
The MinGW lib folder should be at C:\MinGWStudio\MinGW\lib.
After that, open the include subfolder in the archive and extract the folder named "SDL" to the MinGW include folder, which should be at C:\MinGWStudio\MinGW\include.
Note: Some versions of SDL won't have a folder named "SDL" in the archive's include subfolder, but just a bunch of header files. To get around this simply create a folder named "SDL" in your MinGW include folder and copy all the header files from the archive to that folder you made.
Now take the SDL.dll from the archive (it should be inside the bin subfolder) and extract it. You're going to put this in the same directory as your exe when you compile it.
Alternatively, you can copy SDL.dll to C:\WINDOWS\SYSTEM32 so your SDL app will find SDL.dll even if it's not in the same directory. If you're using a 64bit version of Windows, you'll want to put the dll in C:\Windows\SysWOW64.
The problem with this method is if you have multiple SDL apps that use different versions of SDL, you'll have version conflicts. If you have SDL 1.2.8 in SYSTEM32 when the app uses 1.2.13 you're going to run into problems. Generally you want to have your SDL.dll in the same directory as your executable developing and you'll always want to have SDL.dll in the same directory as the exe when distributing your app.
Now start up MinGW Developer Studio and start a new empty project.
Go to the project settings.
Under the Link tab, paste:
mingw32, SDLmain, SDL
in the libraries field.
Add source new source file to the project and paste the following code into the new source file:
//
#include "SDL/SDL.h"
int main( int argc, char* args[] ) {
SDL_Init( SDL_INIT_EVERYTHING ); //Start SDL
SDL_Quit(); //Quit SDL
return 0;
}
Now Compile. Save the new source file if necessary and make sure SDL.dll is in the same directory as the executable. If there are no errors, you're finished. Otherwise go back and make sure you didn't skip a step.
Related
I am new to programming and I am trying to use SDL library with Code::Blocks on Windows. I downloaded the Library from : https://www.libsdl.org/download-2.0.php.
I downloaded the files, decompressed and then copied SDL.dll file in
C:\Program Files (x86)\CodeBlocks\MinGW\bin
and then the include and lib files in
C:\Program Files (x86)\CodeBlocks\SDL,
which is a new file I created. However, when I open Code::Blocks, new SDL project and arrive at the step where I am supposed to give the directory where the include and lib files are, once I hit next I get the following error :
The path you entered seems valid but the wizard can't locate the following SDL's library file: SDLmain in it.
Any idea why this might be happening and how I can fix it?
I want to use Qt in my new project. An installer for my target compiler (VS2010 64bit), does not exist.
I am using Windows 7 64-bit with Qt 5.1.1.
A colleague of mine is also planning on using Qt and has managed to compile it for my target compiler (which he uses as well). He has built it in some directory, say DirA. He graciously gives me a copy of his entire Qt SDK build (binaries, examples, headers, and all), and I copy it to DirB on my machine.
I need it in DirB, because that is where all my 3rd party libraries are installed, and my CMake scripts know how to find them. I also added the Qt bin folder to my path.
Problems ensue. Qt binaries for some reason have the install path (in this case the build path) hard coded within them. So even though the Qt bin folder is in my path (so DLLs are found), Qt's DLL(s) are looking in the wrong place for the windows "plugin". They are looking in DirA, which does not exist on my machine.
So from what I found researching, using a qt.conf file specifying the install path root, is supposed to be the way to go. I add one to my Qt bin dir, and now Qt binaries (assistant, qmake, etc) can run.
But now I build one of the examples. Builds fine. Run the exe, Qt DLLs load, and then it crashes because it can't find plugin directory.
A work-around my colleague and I found that seems to work, is to copy my qt.conf file to the directory my exe resides in. After doing that the exe runs.
But this does not seem right. My exe can find the Qt DLLs, but the Qt DLLs it loads can't find qt.conf. They don't know to look in their own containing folder. I must have qt.conf in my working directory (my exe dir) for it to be found and used.
Does anyone know why this might be happening, and know of a way for me not to be forced to have a qt.conf file in my exe's dir? I can't accept this requires a rebuild of Qt. There must be some other way.
You can put qt.conf into your binary. Using the resource system.
From the Qt docs:
Without qt.conf, the Qt libraries will use the hard-coded paths to
look for plugins, translations, and so on. These paths may not exist
on the target system, or they may not be accesssible. Because of this,
you need qt.conf to make the Qt libraries look elsewhere.
QLibraryInfo will load qt.conf from one of the following locations:
:/qt/etc/qt.conf using the resource system
Or:
Using QApplication::addLibraryPath() or
QApplication::setLibraryPaths(). This approach is recommended if you
only have one executable that will use the plugin.
If you add a custom path using QApplication::addLibraryPath it could look like this:
qApp->addLibraryPath("C:/customPath/plugins");
I have tried configuring gtk+ on visual studio but doesn't work properly.,
Can anyone suggest me with a proper solution, as how to install gtk on Visual studio 2010
I got GTK+ working with VS2010, so if you want to get it working too, get ready for some fun, because this will take a few minutes.
First of all, download the latest Windows All-In-One bundle. Optional direct download link for the GTK 2.24 bundle that I used here. The direct link is to the 32bit version. I have not tested the 64bit version because it is still listed as experimental.
Once you have the bundle downloaded, unzip it into something like C:\gtk or in my case D:\gtk
Next we will create a System Environment Variable for the GTK folder. Open up a command prompt and write: setx GTKDIR {Path to your GTK folder} /m which in my case would be setx GTKDIR D:\gtk /m
We are also going to add the .dll files required for GTK+ built applications to run on Windows into our system PATH. To make things very easy, I suggest you edit your system PATH with PathEditor. Now add the path to the GDK binaries folder which in my case is D:\gtk\bin to the system PATH. Confirm the GTK bin folder has been added to the PATH by typing PATH into your command prompt.
Now we move on to Visual Studio 2010 and create a new project.
File
->New
->Project
Visual C++
->Win32
->Win32 Console Application
Then the Application Wizard Appears.
Click to select:
Windows Application
Empty Project
click Finish to proceed.
Before we add any source files, right click on the project name in the Solution Explorer and click on Properties. Now go to Configuration Properties and then VC++ Directories. We now need to add the include and library files from GTK to the Include Directories and Library Directories.
You should have the following in your Include Directories
$(GTKDIR)\lib\gtk-2.0\include
$(GTKDIR)\lib\glib-2.0\include
$(GTKDIR)\include
and Library Directories:
$(GTKDIR)\lib
While we are still in the view of the Project Properties, click on Linker and then System. Look for SubSystem on the right and click the drop down box. Select Windows /SUBSYSTEM:WINDOWS
Next up, we have to generate the flags for the compiler and the linker. Luckily, GTK+ comes with a nice little tool called pkg-config that we will use to automatically generate these flags for us. The pkg-config tool can be found in the bin folder of GTK. In my case this is D:\gtk\bin or %GTKDIR%\bin using our system variable that we defined earlier. Simply navigate to the bin folder(the created text files will be output there) using the command prompt and run the following:
pkg-config --cflags gtk+-2.0 --msvc-syntax > compilerflags.txt
This will create the compiler flags we need and store them in a text file.
My Result for compiler flags (I have removed the flag -mms-bitfields, this is a gcc only flag that we don't need):
-ID:/gtk/include/gtk-2.0 -ID:/gtk/lib/gtk-2.0/include -ID:/gtk/include/atk-1.0 -ID:/gtk/include/cairo -ID:/gtk/include/gdk-pixbuf-2.0 -ID:/gtk/include/pango-1.0 -ID:/gtk/include/glib-2.0 -ID:/gtk/lib/glib-2.0/include -ID:/gtk/include -ID:/gtk/include/freetype2 -ID:/gtk/include/libpng14
We will do the same for the linker flags:
pkg-config --libs gtk+-2.0 --msvc-syntax > linkerflags.txt
My Result for linker flags:
/libpath:D:/gtk/lib gtk-win32-2.0.lib gdk-win32-2.0.lib atk-1.0.lib gio-2.0.lib pangowin32-1.0.lib gdi32.lib pangocairo-1.0.lib gdk_pixbuf-2.0.lib pango-1.0.lib cairo.lib gobject-2.0.lib gmodule-2.0.lib gthread-2.0.lib glib-2.0.lib intl.lib
With all the needed flags generated, we need to add them to our project. Once again, right click on the project name and click on Properties. Now go to C/C++ and click on Command Line. To the right you should see an empty box called Additional Options. Copy and paste the compilerflags.txt content into this box.
After finishing the above, click on Linker and then Command Line. Once again, simply copy and paste the contents of the linkerflags.txt file into the Additional Options box. While we are here, add one last linker flag /ENTRY:mainCRTStartup This flag tells Visual Studio that we want to use the standard main() rather than Microsoft's _tmain() as our main program entry point.
Finally, in the Source Files folder, create and add a new .cpp file with the following:
#include <gtk-2.0\gtk\gtk.h>
int main(int argc, char* argv[])
{
gtk_init(&argc, &argv);
GtkWidget* window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_widget_set_usize(window, 300, 200);
g_signal_connect(G_OBJECT(window), "destroy", G_CALLBACK(gtk_main_quit), NULL);
gtk_window_set_title(GTK_WINDOW(window), "GTK+ with VS2010");
gtk_widget_show(window);
gtk_main();
return 0;
}
Everything should now be ready to compile, link and run. If all went well, you should be greeted by the following:
Well that was fun, right? :)
If you're building GTK+ stack on Windows with the help of a guide like this, then the luxuries of using a precompiled binary will not be at your disposal.
In this case I would suggest the following approach.
Download the precompiled binaries - This has two advantages.
This ships with the pkg-config.exe utility which you could use for the compiled source.
This also contains the pkgconfig folder with a wealth of .pc files which can be adapted for the compiled source.
Compile the packages in the debug/release mode - well this is the main advantage of compiling it yourself - and systematically arrange the headers, libs and dlls/exe in include, lib and bin folder respectively.
Copy the pkgconfig folder from the precompiled_gtk_source\bin to compiler_gtk_source\bin and set the path of the PKG_CONFIG_PATH variable
to add the compiler_gtk_source\bin\pkgconfig to it.
Now, considering the fact the names of the libraries produced on compiling gtk yourself and the corresponding library names in the precompiled package may be different, you might have to make the necessary changes in compiler_gtk_source\bin\pkgconfig*.pc files. I would go for a top-to-bottom approach here( We will see the advantages shortly). By top-to-bottom, I simply
mean that the end product will be the one to be edited first.
For example in this case the gtk+ is the end product and I will go for
configuring the .pc of this package first. The procedure is as follows:
First look at the name of the dll created. In my case it is gtk-3.0. If the .pc file that was shipped with the precompiled binaries have another name, then change the name appropriately - in my case it is gtk-3.0.pc. (This should be the case with all the other .pc files.)
Open the gtk-3.0.pc in a text editor and you will see stuff like below.
gtk-3.0.pc file:
prefix=c:/gtk_compilation/vs12/win32
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
targets=win32
Name: GTK+
Description: GTK+ Graphical UI Library
Version: 3.18.2
Requires: gdk-3.0 atk-1.0 cairo cairo-gobject gdk_pixbuf-2.0 gio-2.0
Requires.private: atk
Libs: -L${libdir} -lgtk-3
Cflags: -I${includedir}/gtk-3.0 -mms-bitfields
The one above is my customized file. If you don't know what each line does,
you could have a look at pkg-config help. The Require option,
however, needs a special mention. It is the place where you put the
dependancy dlls - again make sure that the name of the dlls exactly
matches what you have in your bin folder.
We need to recursively change the .pc files for the dlls which are included after the Require statement and if any .pcs are missing or if there is a name mismatch, you could make the appropriate changes. By now, you should already have understood the advantage of top-to-bottom approach. It helps us to sort out dependency .pc files systematically until we sort out all of them.
Now, run the below command to see if things are working.
Finally run the pkg-config command like below :
pkg-config --cflags gtk-3.0 --msvc-syntax > compilerflags.txt
pkg-config --libs gtk+-2.0 --msvc-syntax > linkerflags.txt
I just redirected the results to a text file named compilerflags.txt & linkerflags.txt so that you could use them any time you want by cut,copy & paste. Ofcourse, you should retain only the compiler specific flags.
Hope this helps somebody, sometime.
Give a look at this GTK+ with Visual Studio 2008 tutorial.
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.
I'm trying to distribute my app's dependencies with the app.
I've got the macports packages librsvg, boost, and cairo installed 64-bit-only on my Snow Leopard system. When I create an .app bundle of my program, it does not work on machines without macports and the relevant libraries installed because they are not included with the app, which searches for the libraries in /opt.
I have tried the --static flag for static linking, but that caused libcrt0 errors.
What's the best method for linking MacPorts libraries and their dependencies to an OSX application suitable for lone distribution?
You'll want to copy the libraries into your application bundle, using a Copy Files Build Phase. dylibs should be put in the Frameworks directory in the app bundle. You'll also have to add the libraries to your Xcode project.
Try using py2app to create a stand-alone app.
I had to just do this for jsoncpp. What I did was I went to linker settings under the project > Build Phases > Link Binary With Libraries then used the add other to go to my library's path and add the library from the folder which would be under opt/local/lib in the default setup for macport
getting the header files was a bit more complicated. In this case I had ended up going to usr/Include finding the file/folder with the headers, copying it into my project and in the cpp file I added the include line with quotation marks ("")
e.g., moved /usr/Include/json directory into the RestTemplate Project folder using copy. then added to main.cpp
#include "json/json.h"