I'm trying to add support for Ogg Vorbis in my project (C++, VS 2010). I had no problem compiling LibOgg + LibVorbis to produce a static library.
My procedure is this:
LibOgg
Download LibOgg
Build LibOgg with dynamic solution (Release)
Get a libogg.lib export and a libogg.dll in /Release folder
LibVorbis
Download LibVorbis
Set appropriate include + library folders for LibOgg
Build LibVorbis with dynamic solution (Release)
Get a libvorbis.lib and libvorbisfile.lib exports and libvorbis.dll and libvorbisfile.dll in /Release folder
My program
Set appropriate include + library folders for Libogg + LibVorbis .lib exports
Place .dll in working directory
The build succeeds but unlike the static build (which works), the dynamic build just crashes in the first ov_open call (which opens some .ogg file). I built lots of libraries (GLEW, SQlite, etc.) yet this one gives me the nuts.
Never mind, i solve this.
It seems OggVorbis is touchy when it comes to Windows and use of ov_open due to some linking issues with stdio.h and fopen.
Documentation says it clearly:
WARNING for Windows developers: Do not use ov_open() in Windows
applications; Windows linking places restrictions on passing FILE *
handles successfully, and ov_open() runs afoul of these restrictions
[a]. See the ov_open_callbacks() page for details on using
ov_open_callbacks() instead.
Although it is recommended by docs to use callbacks, i found ov_fopen to be reliable which works for both static and dynamic builds with the OggVorbis; the dynamic build will crash your program if you use ov_open on Windows.
Going to update this answer after i test it against Linux and OSX to verify ov_fopen as a safe, all around solution.
UPDATE
As said, i tested the use of ov_fopen on Windows 7, Linux (Lubuntu), OSX (10.8.2) and Android (KitKat 4.4.4) and i found out that works reliably. So, for those allergic to callbacks (like me), ov_fopen proved reliably.
Related
Current ffmpeg depends on CryptAcquireContextW what was deprecated and now removed from Windows. It compiles fine, but on running it crashes with text: "ffmpeg procedure entry point CryptAcquireContextW could not be located in the dynamic link library". advapi32 does not provide it anymore? The net say's it is deprecated already for a longer, however latest stable 4.3.git ffmpeg still depends on it.
Is there a temporary fix possible to compile successfully working ffmpeg for the windows 10 using MinGW?
I recently downloaded goattracker2 on Windows 10 and after making some changes to the source code, I need to recompile the program to test it.
I don't have any experience with recompiling.
I had a look at the documentation included in the readme-file:
Recompiling
To recompile for Win32, you need the MinGW development environment,
use the file src/makefile.win as makefile.
To recompile for Linux, use src/makefile.
In both cases you need the SDL development libraries in addition to
the SDL runtime, see http://www.libsdl.org.
Compile first the utilities (datafile & dat2inc) from the src/bme
directory, and place them to your path.
This leaves me with several questions, like
Which programs do I need to download
How do I run or execute the makefile
Where do I need to install the SDL libraries
If anyone has experience with recompiling goattracker, can they provide a step by step tutorial for how to do it?
Get MinGW (I recommend 32bit version) and install.
Download and unpack the SDL Libraries from https://www.libsdl.org/ (depending on your version you might need SDL 1.x)
The SDL Libraries (the *.a files) have to be added in the lib directory of MinGW installation directory (this might be different from the lib dir of MinGW, see this issue)
The header files from SDL (SDL2/ directory MinGW) have to be put where MinGW can find them (this might be different from the include dir of MinGW, see this issue)
Go to the src directory of goattracker and type make -f makefile.win
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 am trying to compile the Qt library (I don't need the demos or examples) for 64-bit Windows. There are instructions here but I run into the error described in the comment below it. There doesn't seem to be a reference anywhere for how one might go about doing this process.
I am targetting Microsoft Visual C++ 2010 Express. It looks like I need Perl and the Windows SDK as well - how do I go about this process?
This process is quite tedious and time-consuming - but I will explain each step in detail here for the benefit of others who try to compile Qt in the future.
The first step is to install all of the prerequisites.
ActivePerl, which is used during the configuration process. You will need to restart after installing Perl since it modifies environment variables.
The Windows SDK 7.1 (formerly called the Platform SDK). Be sure to include the x64 libraries when you select the components to install.
Download the Qt source archive from the Qt Downloads page.
Extract the contents of the archive to an easy-to-remember location (like C:\). You need to remember this location later since we will be using it to set some environment variables.
Now open the Windows SDK 7.1 Command Prompt. Begin by setting the environment to 32-bit release mode (we need to build some of the tools as 32-bit applications):
setenv /release /x86
Set the following environment variables (example below assumes you extracted to C:\):
set QTDIR=C:\qt-everywhere-opensource-src-4.8.0
set PATH=%PATH%;%QTDIR%\bin
Now run cd %QTDIR% and specify the configuration options - example is included below:
configure -release -opensource -qt-zlib -qt-libpng -qt-libmng -qt-libtiff
-qt-libjpeg -qt-style-windowsxp -qt-style-windowsvista -platform
win32-msvc2010
Once the configuration process is complete, cd to the src directory and run:
qmake
nmake
This process may take a considerable amount of time, so now would be a good time to take a break and answer some questions here on Stack Overflow :)
The tools are now built and you need to compile Qt as a 64-bit library. Enter the following command:
setenv /x64
You will need to set the environment variables from step 5 again. Enter those commands now.
Run cd %QTDIR% and then rerun the configure command being sure to specify one additional option:
configure -release -opensource -qt-zlib -qt-libpng -qt-libmng -qt-libtiff
-qt-libjpeg -qt-style-windowsxp -qt-style-windowsvista -platform
win32-msvc2010 -no-qmake
The -no-qmake option is very important - it indicates that we want to skip the compilation of the qmake.exe program because we want to keep the 32-bit version.
Now things get really complicated here because of some dependency problems. The tools (like moc) that Qt needs to build the core library and some of the other components are listed as dependencies in the src.pro file. This means that the compiler will attempt to build them as 64-bit applications and then try to run them - which will of course fail on a 32-bit system. So what we need to do is edit src.pro and remove those dependencies ourselves. Scroll down near line 85 and look for a line that begins with:
!wince*:!ordered:!symbian-abld:!symbian-sbsv2 {
Each subsequent line in the section lists a sub-target and its dependencies. What you want to do now is remove all dependencies that begin with src_tools_. For example:
src_gui.depends = src_corelib src_tools_uic
Becomes:
src_gui.depends = src_corelib
There might be a better way of doing this, but I haven't figured it out yet :)
Now we cd into the src directory once again and run the following command
nmake sub-winmain sub-corelib sub-xml sub-network sub-sql sub-testlib
sub-gui sub-qt3support sub-activeqt sub-opengl sub-xmlpatterns sub-phonon
sub-multimedia sub-svg sub-script sub-declarative sub-webkit
sub-scripttools sub-plugins sub-imports
This builds only the Qt libraries and skips the tool dependencies. Note that this too may take a considerable amount of time.
You should now have 64-bit libraries in the lib folder that you can link against in your 64-bit Qt applications.
Edit: it turns out that even this wasn't enough since I still ran into some problems when linking the QtWebKit4.dll library (something about unresolved symbols). It turns out that someone else has already found the solution and you need to change QMAKE_HOST.arch to QMAKE_TARGET.arch in WebCore.pro.
Also, the above options will build QNetwork4.dll without OpenSSL support (you won't be able to access sites over HTTPS - even in a QWebView). This, thankfully isn't too hard to fix. Download and build OpenSSL for Win64 and append the options below to the command in step #9:
-openssl -I C:\OpenSSL\inc32 -L C:\OpenSSL\out32dll
(You'll have to change the paths if you installed OpenSSL somewhere other than C:\OpenSSL.)
Further edit: to save the trouble of doing this yourself, I have uploaded the compiled libraries here:
http://www.box.com/s/9710cbb278ef4890a7b5
As I mentioned in the comments to George Edison's answer, there is a bug in the Microsoft Visual C++ compiler that comes with the Windows SDK 7.1. For more information on this, see QTBUG-11445 and QTBUG-19175.
I have compiled the Qt 4.8.2 64-bit binaries following George's instructions, including the OpenSSH library. In addition, I applied Microsoft's hotfix to fix the compiler bug.
For your convenience, I have made the resulting 64-bit libraries available for download from here: https://www.box.com/s/8948c60c3cdd743ef83b
I'm having some trouble installing and configuring qt on my vista laptop.
I'm trying to setup a development environment on my laptop where I compile from the command line, because that's how the environment is setup on my university's linux machines, so I don't want to tie myself to some IDE .. (plus, real programmers use the command line!)
I haven't used the command line before for C++ development, it was all MSVC, so now I'm having a bit of trouble.
I'm still using MSVC, but from the command line. I practically have no idea what's going on, I just know that I have to run:
qmake
nmake
to compile my code!
I downloaded the opensource version of qt, and did the configuration, and tried a simple qt application (from a tutorial) and it worked, it compiled and executed pretty much as expected.
Now, when I decided to run another project that uses opengl, I got the following error:
fatal error C1083: Cannot open include file: 'qgl.h': No such file
or directory
I'm not sure where does the compiler look for header files, and I didn't copy any header files anywhere, I assume that configure.exe worked its magic somehow and added the include directory to one or more enviroment variables or to some registery location or whatever other peculier places that the MSVC compiler searches for to find include directories.
However, what I did was search my C:\qt\include\ folder to make sure that qgl.h exists, and sure enough there it was. so why can't nmake find it?
I think the actual solution to this is in your pro file:
QT += opengl
If you want to stay with the command line anyway (plus use it on a linux box later / parallel) I'd suggest at least trying out the MinGW version of Qt. I'm using it regularly, and besides of the non-existance of a GUI it works pretty well. Using MinGW also has the advantage that you can simply download and install the MinGW edition of Qt and don't need to reconfigure or recompile anything.
Also, trying out QtCreator might be interesting. It's still beta and requires the beta Qt 4.5 but it's a nice small IDE that integrates nicely with gcc.
Two potential solutions (they solved issues at my workplace)
Do you have qt include and bin folders in the PATH variable? I think the doc says only one of these is needed, but one of the students had Vista and putting the other in the PATH variable solved a "Cannot open include file" problem.
If you're using MSVC did you run configure and nmake from the Visual Studio command prompt? We had problems when using the bare windows Command Prompt because the VS one adds a lot of temporary environment variables to the configure process.
Good luck
Install the complete Qt SDK for Windows which includes Qt 4.6 SDK, Qt Creator 1.3, and MinGW.
It will also install "Qt Command Prompt" launcher that you can use to build Qt apps from the command line.
I'm sure you're more familiar with MSVC than MinGW, as I do too (I've been using MSVC 6.0 to MSVC# 2008 for developing .NET apps).
But try MinGW with Qt and I think it's better for long term. I do some C++ development on Linux too so getting familiar with MinGW will be beneficial for you in cross-platform C++/Qt development.
For more info, see Installation of Qt 4.6 SDK for Windows.
Qmake generates Makefile from *.pro file located in current directory. It has qt path compiled in. Type "qmake -v" to see it. You can't move qt's dir after compiling it. If You haven't moved it, first maybe try to install Qt following instruction from INSTALL file. Good luck.
The opensource version of Qt does not provide profiles (mkspecs in qt terms) so qmake can generate nmake (msvc) compatible makefiles.
You have to use mingw/gcc.