I'm attempting to add Oauth2 to an existing program. The program uses C, and is compiled on a Windows machine using Visual Studio 2010. I believe I need the Iddawc library, recommended by Okta, but they do not provide pre-built libraries, and the code is designed to be built on various flavors of Linux.
I tried downloading Make for Windows, but despite there being a Makefile, when I run it, I get this message:
make: *** No targets specified and no makefile found. Stop.
I've also attempted to include the library files in the existing project (an ugly, temporary solution at best), but this sends me down a seemingly unending chain of other libraries that are required and does not appear to be a feasible option.
Is there a (hopefully simple) way to get this library to build on Windows?
For iddawc, you could try building with MinGW-w64. The easiest way to do that is by installing MSYS2.
An alternative that might work for you is liboauth2. At a glance, there's some Windows code in their codebase.
Related
I have a tool in C that needs libpng, zlib and lcms libraries. On unix I get these dependencies via pkg-config, but on Windows I can't rely on it, so for users building the library it's a massive hassle to obtain and build these dependencies manually.
How can I automate obtaining these dependencies in the most Windows-native way? I know MinGW helps, but that's a bit of a cop-out. I'd like to learn how to do it with the Microsoft toolchain.
Is there any point in searching for shared non-Microsoft libraries on Windows, or should I go straight for statically linking my own?
If I were to download and build the libraries as part of my build script, what should I use? (nuget? curl? ftp.exe?)
It seems like Microsoft is discouraging use of NuGet for C? https://github.com/Microsoft/vcpkg/blob/master/docs/about/faq.md#why-not-nuget
I recommend looking into Nuget. It's fast becoming the Microsoft standard for these sort of things. A lot of people think Nuget is just for .NET, but it works great for VC++ too. I have had a great deal of success setting up Nuget servers in my company to serve headers and compiled libs, and I've gotten all of our automated build systems to create these things automatically. I'm not going to spell out all the details here, but it basically comes down to performing your build, creating an MSBuild XML snippet to set up the precompiler and link options automatically, and then packaging all those bits (headers, libs, XML) in the correct way. When done correctly, it's just a two step process to use an existing package in a new project -- establish the Nuget reference and then add the #includes into your code. You don't even need a server -- you can source them directly from a directory of your own control.
https://learn.microsoft.com/en-us/nuget/create-packages/native-packages
I'm either failing hard at Google today, or this is something which is non-trivial.
I have an application that I am working on for a Windows system, cross-compiling from Linux because (a) I need C99 and Microsoft's free tools for the target system does not support it and (b) I've been using UNIX for nearly 30 years anyway, and that's my "home". Changing to an MSVC stack with "native" building is not an option for me, nor is running the GNU build system on Windows (it takes forever).
The problem is that I need to have a single tool built for the system being compiled on and not the target; I need to then run that executable which will generate several .c source files and .h headers which then enable the project to compile. I am using the so-called "GNU Build System" (that is, the autotools, including autoconf/automake/libtool).
Any recipe I write will, regardless if I configure for i686-w64-mingw32 or x86_64-w64-mingw32, compile all DLLs and EXEs for the Win32/Win64 platform.
There is a way that I can force the issue by hand-crafting standard Makefile receipes, but I was trying to find an "autotools native" way of compiling and running build-time executables that are not e.g., unit tests, but source code generators.
Any ideas, short of hand-crafting Makefile recipes?
ETA: Additionally, the project is cross-platform: it does make sense to compile this one natively for Linux as well, so any solution needs to work just as well when not cross-compiling.
I'd like to know the definitive method of building a Qt 5 application on Windows such that no dependencies whatsoever are required to run it, in particular the C runtime. I want to be able to distribute the final .exe with no prerequisite software/DLLs required. In particular, I want to avoid requiring my users to have to install vcredist.exe for MSVC*.dll or the MinGW redistributables.
I'll happily use either of the compilation environments (MinGW or MSVC), and will rebuild Qt from source if that is a necessary step (though I'd like to know if it is indeed necessary).
You have to static build the code. Chech this link explaining step by step method to build your code statically. http://qt-project.org/wiki/How-to-build-a-static-Qt-for-Windows-MinGW#9731f56412bd237286d3271405d55fd2
There is few files with .c anf .h extensions (cmdline.c cmdline.h core.c core.h and so on) in src directory, also there is one file "MakeFile" without extension. Is there any possibility to build these source files into some executable file on Windows 7 (64bits) ? I think i need to download compilers for C or some sdks right?
Yes.
You need to:
download and install a C/C++ compiler (I recommend TDragon's distribution of MinGW ),
add the compiler to your PATH (the installer can do it for you most of the cases); verify it's done by opening cmd.exe and typing gcc -v and mingw32-make -v, both should give you half a screenful of version information if your path is set correctly,
via cmd.exe, navigate to the folder in which the Makefile resides and call mingw32-make.
From now on everything should compile automatically. If it doesn't, post the errors.
Update:
First of all, it'd be useful for you to get the MSys package. Install it and you'll have a more recent version of make (use it instead of mingw32-make from now on).
About the CreateProcess bug, it has to do with the system PATH variable being too long. You'd need to do something like this:
open cmd
execute set PATH=c:/mingw32/bin;c:/msys/1.0/bin (change the paths here to reflect your own installation if it's different)
then as before: navigate to your project's directory, run make. Everything should be smooth now if you're not missing any external libraries.
BTW- remember not to install MinGW or MSys in directories with spaces.
I am not a Windows Developer..
But still as per my knowledge. Visual Studio (i.e 2008, I guess) has the ability to read the Makefile.
Please have a look at it..and if needed change this makefile to their format..
There are many opensource product which are platform independent..and they get compiled on both OS with the just Makefile they provided.
Or else use 'cygwin'
Developer C++ works in windows but it is actually GCC code bought into Windows, Is anyone familiar about the procedure they used to convert the linux ( .sh) to executables ??
I think i need to download compilers for C or some sdks right?
A compiler certainly, but what additional libraries you may need will depend entirely on the code itself. A successful build may also depend on the intended target of the original code and makefile. The makefile may be a GNU makefile, but there are other similar but incompatible make utilities such as Borland Make and MS NMake. If it is a simple build, you may be able to avoid the makefile issue altogether and use the project management provided by an IDE such as Visual C++ 2010 Express.
If you do not know what this code is or what it does and what it needs to build, you are taking a risk building it at all. Maybe you should post a link to the original source so that you can get more specific advice on how to build it.
[EDIT]
Ok, now looking at the code you are attempting to build, it is a very simple build, so if you wanted to avoid using GNU make, then you could just add all the *.c files in the src folder to a project in your IDE and build it.
However there is one serious gotcha, it uses the BSD sockets API and Linux system headers. You will need to first port the code to Windows APIs such as WinSock (very similar to BSD Sockets), or build it under Cygwin (a sledgehammer for a nut somewhat). There may be other Linux dependencies that need sorting, I have not looked in detail, but it looks fairly simple. That said, if you did not have the first clue regarding compiling this stuff, then perhaps this is not a task you could do?
Of course compiling the code may only be half teh problem, if it was designed to run on Linux, there may be run-time dependencies that prevent it running on Windows. Again I have not looked in detail.
Also looking at the code, I would suggest some caution, this may not be the best quality code. That may be unfair, but one obvious flaw and an indication if inexperience is the lack of include guards in the headers.
I am in a big problem ..i have compiled my c files using linux make file in Linux OS.
I want to compile the same files in Windows using the same make file by command prompt. For that i have nmake utility and Cygwin utility too.
I have done that successfully with simple programs with simple make file ..
But it is not possible to compile when i was using the complex C files with complex make file.
I have changed the '/' in linux make file to '\' in windows? Anyother changes?
I want to know 'Is there any special make file formats in windows?'
also the difference between them..
I am really in need of that...
Unfortunately, nmake was only loosly inspired by make, and they didn't get many important things right. By far the easiest thing to do is to start by having the same flavor of make on both platforms.
On linux, Gnu make is the default and best option.
On Windows, there are several sources for Gnu make, with some quirks to choose among. Personally, I mostly use the native win32 build of Gnu make from the GnuWin32 project. You might want to poke around at the rest of the project's packages because some of the others will be useful to have as well.
Alternative sources are Cygwin and MinGW32/MSYS.
Cygwin is a credible attempt at providing a *nix compatibility environment on top of the Windows kernel. It consists of a DLL that exports a huge percentage of *nix (especially POSIX) system calls implemented via the Windows API. That DLL also has its own idea about disk mounts and prefers *nix-style path names. The DLL itself is licensed GPL (although a commercial-use license is available for a fee), and programs built in the Cygwin environment require it by default, so that can be a factor to consider. Another factor is that Cygwin is not friendly to normal Windows users, so development projects based on it usually end up difficult for non-unix users to deal with. For a cross-platform developer, however, Cygwin can be really useful as it gets you all of the usual suspect utility programs required by your Makefile, and it includes the MinGW32 native Windows targeted GCC as well as a GCC targeting the Cygwin environment.
MinGW32 is a porting project that did a really good job of porting the GCC compilers to run as native Windows executables. If used along with the header files they supply, it is possible to use nearly all of the Windows API via a C runtime DLL that ships with modern Windows installations.
MSYS is a lightweight fork of Cygwin that contains a minimal set of utilities (starting with a *nix shell) that are usually assumed to exist by a typical *nix Makefile. Unlike Cygwin, MSYS is configured such that the default target is the native Windows API.
What I'm trying to hint at here, and probably should just state flat out, is that your compatibility issues don't end with the dialect of make you use.
The Makefile language itself is highly dependent on the command shell available, and most serious project Makefiles end up using many of the *nix the core utilities such as cp and rm.
I would strongly recommend starting with the GnuWin32 build of make, and also installing MinGW32 and MSYS. It is then relatively easy to write a Makefile that works under both MSYS and linux, and needs only a small amount of platform-specific logic.
You should consider CMake for cross-platform make but your real problem is you shouldn't have to change the '/' to '\'. If you run under cygwin or msys (recommended) this should be handled for you.
NMake is a windows tool and will parse only windows-style paths, i.e. paths with drive letters and backslashes. Therefore you should use GNU Make installed with cygwin.
nmake should read your makefiles okay, the differences are generally between versions of make rather than OSs.
The big question is what your target platform actually is, are you trying to make this code operate in Windows natively or are you looking to run it under Cygwin?
Use gnumake on both platforms. I do. I haven't touched Visual C in years.
nmake got it's own format rather than windows itself, so makefile format is related to make tool rather than os. For simple things format is similar for g(nu)make and nmake, as people suggested before consider using gmake only.