I have run in to a problem when programming with windows api. I want to use OpenGL's shader capabilities in my project. I included and linked GLFW with my project but got this error.
warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
Should i be using GLWF with Windows API or should I be using something else completely ?
The problem you have is caused by the GLFW binary you're trying to link using a different CRT than what the linker wants to link with your program. In particular the brew of GLFW you have seems to have been build with either a VC++ compiler of Visual Studio 6 or older or the MinGW compilers.
Since a modern MSVC++ compiler will refuse to link against system MSVCRT without jumping some serious hoops (od you'd have to use the Windows DDK compiler for that), the two options open to you are:
get a DLL build of GLFW into which the CRT has been linked statically
build a DLL version of GLFW with the very compiler you use right now
build a static linked library variant of GLFW and link it statically to your program (static library build usually are not tied to a particular CRT).
Firstly, why would you want to be using Windows API at all? If you're using OpenGL then a multi-platform API such as GLFW would be wise since it handles the Windows API stuff for you. If you want to use Windows API then that's your choice, the same with GLFW. But remember not to mix the two together, otherwise there will be a conflict. In my opinion, if you use GLFW your code will be portable to other operating systems.
Related
Let's say I have retrieved some C/C++ original and unmodified distribution libraries that were specifically designed for the Unix-POSIX based environments where the original developers who designed their code wrote them specifically for their environments - systems and these libraries originally are not portable to modern Windows systems.
What I would like to be able to do is to at the least build the needed static or dynamic libraries to be able to link them against my own Visual Studio projects.
I know that with Mingw(clang) you only need the MSVC run-time libraries as it doesn't have any need of the POSIX dll dependencies as it uses the Win32 libraries directly. However, it doesn't have all of the Unix environment features that Cygwin(gcc/g++) does and for any C/C++ code that relies on native POSIX functionality such as fork(), mmap(), etc. would have to be re-implemented into the Win32 equivalents for proper compilation, linking, and running of the application.
With Cygwin I'm more exposed to nearly all of the Unix-POSIX features with a little higher learning curve and to integrate these libraries that are built by Cygwin's compiler(s), they would rely on cygwin1.dll to be able to run on a Windows machine.
A Primary Example:
The current libraries that I'm trying to build to work with Visual Studio are GNU's: GMP, MPIR, MPFR, MPFRC++.
So far I have successfully been able to build MPIR in Visual Studio 2017 with the aid of Python and Windows version of Yasm. However, when trying to build MPFR it requires the dependency of GMP. So now I have to build GMP.
I could use Mingw to build GMP which may be in some ways a little easier, but by using Gygwin and building GMP through the Unix/Linux/POSIX environment I would be exposing myself to the functionality of Unix/POSIX systems.
Note - I'm primarily familiar with Windows environments and until recently have never worked with or on any Unix based OS. So there is a bit of a learning curve for me. I'm doing all the research and reading that I can on my own which is not a problem. It provides good experience with every bit of trial and error.
What I would like to know is when working on a Windows machine; what would be the preferable method between the two case scenarios to build POSIX designed libraries to be able to link properly into MSVC Window's based applications? Another words, I would like to efficiently convert POSIX specific libraries to be able to work on my current platform or machine. Notice that I did not say that I wanted to "rewrite" the libraries to make them portable to any arbitrary environment. In this specific case I only need them to run on my Windows environment. Or any other appropriate method. I will be using some C and some C++ libraries to be linked into my MSVC c++17 project(s). (I may also have some of the terminology wrong in some of my above statements or assumptions as I'm not familiar with Unix-POSIX environments).
I was wondering which compiler is better to use on Windows OS (8.1) in temrs of compatibility to c++11's (and later 14) functions, liberies and features (like lambdas) and is also comfortable to use (less bugs).
I am a university student hence I'm not looking at the subject product-wise (even though I do like to code a bit more than just projects for my studies).
I am currently using eclipse luna IDE if it matters.
Notice that compiler != IDE.
VC++ is one of the most populars on Windows and depending on its version it has a good support for C++11 features. Check the list on the msdn blog to find out if there's everything you need.
Gcc is also ported to Windows and you can install MinGW to use it (4.8.1.4 at the moment of writing this). It is pretty complete on C++11.
Clang is also available for the Windows platform and it is also complete on C++11 support (plus it has good diagnostic messages), but notice that you will have to use another linker since clang doesn't ship with one (although there is an ongoing effort to write it: http://lld.llvm.org/)
All the compilers I cited above are pretty stable but, based on my experience, if you're looking for latest and greatest C++11/14/17 features, you might just want to go for gcc or clang (VC++ is slower in adding support for newest features and the compiler is undergoing a huge update to modernize). Just keep in mind that these are compilers and not just IDEs, an IDE is a front-end supporting program that uses a compiler undercover to compile files.
To set up a C++11 compiler, I suggest installing MSYS2, it has a package manager (pacman) that can install fresh versions of GCC, GDB, Clang and many libraries like SDL, Lua etc. Very easy to use too.
As far as GCC vs CLang goes - I really tried hard to make CLang work (which is presumably faster and more friendly than GCC - produces better warnings, etc.), but failed. Issues were that CLang (which comes with MSYS2) is hard-coded to use GCC linker which produces some strange linker errors when using libstdc++ (std implementation from GCC). libc++ (a new implementation designed to work with CLang) didn't worked for me on Windows either.
So you either try build CLang from sources and hope that some configuration will work with C++11 library, OR just stick with GCC which works just fine out of the box.
As IDE, I suggest to take a look at CLion. It is very comfortable (infinitely more user-friendly and intuitive than Visual Studio, IMO). Just install it and point it to the mingw64 (or mingw32) folder of MSYS2, it will auto-detect everything for you.
It only works with CMake projects though.
I've been browsing the LLVM documentation, and I've got to ask about the availability of back-ends for Windows. Their examples for getting up and running on Windows still use the Visual Studio linker to create the resulting executable files. The JIT example is much cleaner, but I need to create output PE files, not JIT the code in-process.
What I'd like to ask is if there exists an LLVM backend which can perform virtually all of the necessary functions to go from LLVM IR to executable PE file, including handling the importing of Win32 functions from the kernel, and preferably, handling COM types as well.
Sadly not. LLVM itself doesn't handle any of the linking stages, it's just a compiler, so you'll need to integrate it with the Windows SDK linker, or the linker from MinGW.
I'm currently compiling an open source optimization library (native C++) supplied with makefiles for use with gcc. As I am a Windows user, I'm curious on the two options I see of compiling this, using gcc with MinGW/Cygwin or manually building a Visual Studio project and compiling the source.
1) If I compile using MinGW/Cygwin + gcc, will the resulting .lib (static library) require any libraries from MinGW/Cygwin? I.e. can I distribute my compiled .lib to a Windows PC that doesn't have MinGW/Cygwin and will it still run?
2) Other than performance differences between the compilers themselves, is there an overhead associated when compiling using MinGW/Cygwin and gcc - as in does the emulation layer get compiled into the library, or does gcc build a native Windows library?
3) If speed is my primary objective of the library, which is the best method to use? I realise this is quite open ended, and I may be best running my own benchmarks, but if someone has experience here this would be great!
The whole point of Cygwin is the Linux emulation layer, and by default (ie if you don't cross-compile), binaries need cygwin1.dll to run.
This is not the case for MinGW, which creates binaries as 'native' as the ones from MSVC. However, MinGW comes with its own set of runtime libraries, in particular libstdc++-6.dll. This library can also be linked statically by using -static-libstdc++, in which case you also probably want to compile with -static-libgcc.
This does not mean that you can freely mix C++ libraries from different compilers (see this page on mingw.org). If you do not want to restrict yourself to an extern "C" interface to your library, you most likely will have to choose a single compiler and stick with it.
As to your performance concerns: Using Cygwin only causes a (minor?) penalty when actually interacting with the OS - where raw computations are concerned, only the quality of the optimizer matters.
MSYS and UNIX-like build systems apart; why does Mingw exist? What I mean is, why isn't win32/64 just another target available in "vanilla GCC"? Are there technical reasons for this or are they "political"? It would seem to me that there isn't really anything special about the Windows platform that would make a GCC port to it "incompatible" with the original GCC.
Mingw isn't just the compilers - it's also the libraries and headers (and whatever other support files you might need).
GCC is just a compiler. Mingw is a full environment.
MingW is intended to allow easy porting of Posix apps to windows. It's simply a "thinner" layer than CygWin, so not everything might work where windows too different. CygWin allows provides enough insulation that even the scripting tools to build and generate code run.
Edit:
Microsoft is very fond of making there own standards, and want to put there own brand on things for which open standards already exist. i.e. OpenGL -> DirectX, Java -> .net, OpenCL is the next standard they want to spurn. This makes them a bit of a pain for non sponsored project to support them as a target. They have always turned away from anything that allows easy cross platform development, because they only want you to develop your app for there OS. It's a marketing strategy, control the brand, control the platform, and make it painful for people to support other OSes. MingW is required because GCC can generate x86 code, but even the most basic runtime support is different than Posix based OSes.
well, while you can use cross compiler to produce win32/64 binary codes from GCC, someone has to port all the C runtime libraries across though. Both Mingw and Cygwin are created for this purpose.
From MinGW's main site
Offered in easily installed binary package format, for native deployment on MS-Windows, or user-built from source, for cross-hosted use on Unix or GNU/Linux, the suite exploits Microsoft's standard system DLLs to provide the C-Runtime and Windows API.