Compiling From Sources Windows 10 msvc14
-
I am needing to use QT for PCL, I was attempting to compile QT5 when I realized that win 10 64-msvc14 isn't supported. I am new to the open source community and compiling in general, I have compiled everything else I needed for PCL using win10 64-msvc14. If I were to use vars for windows 8.1 msvc 13 will I be able to use qt in my project? Or would I need to recompile all of my other dependencies using msvc-2013, to utilize QT.
FYI I am following the QT build process here http://doc.qt.io/qt-5/windows-building.html
and my qt5vars.cmd contains these lines(I set it like this to attempt a compile it ran through the whole process but at the end provided me some errors):
CALL "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x64 8.1
SET QMAKESPEC=win32-msvc2013
-
Hi, welcome to devnet
I realized that win 10 64-msvc14 isn't supported
It is supported. There's just no precompiled binary for it. There's gonna be with Qt5.6 next month. For now you can just compile it yourself. I'm doing it and it works fine.
In general you can't mix libraries built with different MSVC versions. Mixing VS2015 and VS2013 is a definite no go. You have to have built all with either one or the other.CALL "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x64 8.1Should be
CALL "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x64i.e. drop the8.1part.SET QMAKESPEC=win32-msvc2013You are building with MSVC 14.0 which is VS2015 so this should be
SET QMAKESPEC=win32-msvc2015.If you're having errors post them here. Otherwise we're guessing ;)
-
Hey thanks for the help, that did the trick. I think my problem was I had set QMAKESPEC=win32-msvc2014 not 2015 when I was trying it out.
Just curious the win32 would that need to be win64 for a 64 build... I'm guessing not since that doesn't work, and I'm guessing that is handled here CALL "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x64
-
It's a historical name mess. Back in the old days there was "win" and when 32 bit Windows came out and a distinction was made to win16 and win32 it was a nightmare because of hardcoded paths, names and whole lot of shims needed to be applied just to keep things working. With 64 bit Windows some people though it would be a good idea not to repeat the same mistakes (which they did anyway in other ways) and not change the name. win64 became a synonym for another "flavor" of 64 bit architecture ia64, which didn't really catch on. So now win32 basically means "Windows" and does not really refer to the bitness. Similarly you'll notice how on 64bit Windows there's a "Program Files" and "Program Files (x86)" folder, which again has nothing to do with a platform, as x86 is an architectural family and there are multiple 32, 64 and even 128 bit flavors, so technically both these directories are for x86 apps. For various reasons we now refer to 32bit as x86 and to 64bits as x64, amd64 or x86-64.
It also goes for distinguishing Visual Studio versions. There's a MSVC compiler version number and there's a Visual Studio version number and one is a number and the other is a year. But since we usually shorten the years another chaos is born. So you'll see things like msvc2015, which don't exist. "msvc2015" really means "MSVC 14.0 in Visual Studio 2015". See also here.That's just the tip of an ice berg. The story goes on and on. The point is it's a total mess and you shouldn't really get attached to the numbers in names. They are usually really off as to what they refer to.
-
Haha, well's that great. Thanks for the history lesson, and thanks for all the help.
