Hobbyist and newbie, so no laughing ;)
I have been developing some toy programs on my Mac for a long time and everything is nice and straightforward.
I was trying to port one of my existing projects to Windows (as a way to get started in developing for Windows) but am stuck trying to build the libraries I have come to love in a Unix environment under Windows (and MinGW).
At the risk of revealing my naïvety, could someone just run through how to build and install a library on Windows (including any special software required)?
For example, an install readme might look like this:
Do this to install:
./configure
make
make install
Obviously on Windows that pukes...so what are the analogous steps on Windows?
You have a couple of options wrt building unix style libraries on windows:
Google for a pre-built binary distribution made for windows of the library in question.
If the libraries authors have bothered to support it, you can try installing Cygwin to get a posix like build environment on windows
Some libraries - like OpenSSL - have a set of build instructions for windows that include installing ActiveState Perl, and then running the appropriate configure script manually.
Where the authors of the library have made no special effort, you are pretty stuck: Create a static library project in the dev environment, add the libraries files to it, create (or move) the headers that the ./configure step usually creates or moves and build it yourself.
It is a tragic state of affairs that doing this "simple" task is so hard. Developers seem to take one of two lessons away from this:
Microsoft is the devil. Microsoft hates developers. Hates open source software. And is ###$. Compiling libraries and software from source via a standardized ./configure & make install process is the one true way.
Microsoft is the one true way. The microsoft eco system of pre-built .lib files and headers is perfection and people who build everything from source using arcane perl scripts and install into a standardized filesystem are mentally defective.
Your pick :P
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 have a finished program that I would like to distribute to a colleague, and can find no "de-facto" tool chain or resource or guide, or even an opinion, on the best approach to cross-compilation. I know that there is rarely ever a cookie cutter solution, but I am still surprised by the lack of information in this regard.
I have begun trying to cross-compile all of the libraries that I use (and their dependencies) but of course, it is not going smoothly. For reference I decided to go with the basic instructions here. I have followed the instructions exactly as you see them.
Conveniently enough, I needed the png/jpeg/zlib libraries that are used as examples in the link above. I was also able to successfully cross-compile libtiff and leptonica. With that momentum, I then moved on to one of the more beastly libraries -- Tesseract. At this point, during the ./configure .... step, it says that it cannot find leptonica. I don't understand, as the pertinent leptonica files are installed, right where I (and the link above) want them to be. The rub could be rooted in the way that tesseract is built, it differs slightly from the prior libraries I built previously. Tesseract goes autogen.sh -> configure -> make ->make install. I have no idea how to mitigate this.
So my question: Should I continue to bother down this route? The other libraries that I use are openCV, and ImageMagick. If I should, can someone please ease my pain. If I should NOT continue down this route, what is the easiest way to switch to my (very old) windows XP computer, and package up this software? I doubt some of the software I use would even support development on that platform.
I have just compiled some software in cygwin and all went well, except when I tried to run it on a different machine it required some cygwin specific libraries .dll's, is there anyway I can build this in with the software so it can run on third party machines without cygwin installed? Im trying to be generic with the question so the answer will suit other people facing the same or similar problem so sorry for the lack of detail on the software etc. (sgminer)
Thanks for any help
Not only is this a duplicate, as Paul R point out, it's also an FAQ on the Cygwin site.
From "How do I compile a Win32 executable that doesn't use Cygwin?"
The compilers provided by the mingw-gcc, mingw64-i686-gcc, and
mingw64-x86_64-gcc packages link against standard Microsoft DLLs
instead of Cygwin. This is desirable for native Windows programs that
don't need a UNIX emulation layer.
This is not to be confused with 'MinGW' (Minimalist GNU for Windows),
which is a completely separate effort. That project's home page is
http://www.mingw.org/index.shtml.
Is there any difference between makefile in Windows and Linux?
If I know how to use it in Linux, is it necessary to learn
something new when in Windows system?
The fine folks over at GnuWin32 have Gnu make built for Windows as a native binary. It works well, but does have a few minor quirks due to a well-intentioned hack that tries to equate a target named foo with the file foo.exe. The GnuWin32 package does include a nice PDF of the manual, IIRC.
I use it on XP alongside GCC from the MinGW project, as well as with several different embedded systems cross compiler toolchains. MinGW also provides a native build of Gnu Make.
We do use Cygwin for a couple of projects, in particular one where the system-on-a-chip vendor provided a complete, working toolchain and build environment hosted in Cygwin. Moving it to a native Windows shaped build would be prohibitively expensive, and would make it harder to accept updates from the vendor.
If you want to use mostly native Windows tools, but need to start by running configure on an existing source kit, then take a look at MSYS. This started as a fork of Cygwin by the MinGW developers, and it intends to provide a minimal set of unix-like tools with a bash shell so that configure can be used on Windows. It isn't as complete as Cygwin, but it is a lot lighter weight.
You will find that the manual for Gnu Make is mostly true. However, you have to keep in mind that the content of a Makefile is not written in a single language. The stuff that defines variables and lays out the dependancy tree is one language. Each line of an action is a miniature shell script that is in the language of the default shell (which might be CMD.EXE rather than /bin/sh on Windows), and each command has options and arguments.
If you are comfortable with your *nix build environment, then Cygwin might be the path of least pain. But MSYS is often sufficient, and there is something to be said for adopting the native tools of the target platform so that you have a sense of how your users see Windows, in which case MinGW and GnuWin32 are handy resources to know about.
In addition to what iftrue note that Microsoft has a Makefile based build tool called nmake with some changes in syntax/semantics from the traditional *nix based make tool. This page lists some of the differences.
Well, if you download "cygwin", you can run the "make" tool directly on windows, but you may want to look into a true cross-platform build tool such as "cmake". It's like make, but it's a bit more spiffy and is inherently cross-platform.
I've written an application using gtkmm and libpcap under Linux. Of course, gtkmm depends on GTK+.
After porting it to Windows and attempting to distribute it, the feedback I received is that there are too many dependencies to install.
The user has to run installers for the GTK+, gtkmm, and winpcap runtimes before they can run my little application, which admittedly is a pain.
GIMP for Windows seems to use an installer that launches a GTK+ installer if needed, but doing that for three different libraries seems a little excessive, especially in terms of the installer size.
Is there a better way to distribute this? I believe winpcap actually has to install a service, so it probably has to run the installer, but maybe I could bundle the GTK+/gtkmm libraries in the runtime folder?
I'm quite a bit more familiar with Linux development, so I'm not sure what the best course of action is.
I highly recommend using a tool like Advanced Installer to deal with this for you. Making a proper installer on windows is a real headache, so it's well worth your time to use a GUI tool to help you out. AI (and other installers, for that matter) can install and manage windows services, prerequisites, and so on, and in the long run you'll save a lot of time by using a tool like this to help with your deployment. Advanced Installer in particular has very good support for managing different dependencies, along with their associated versions, and it can also install a native Windows service during the install process. They have a freeware version, but depending on the nature of your product, you might want to spring for one of the commercial versions.
Basically, if you're serious about deploying on Windows, you should invest the time (and money, possibly) to make a proper MSI-style installer. Not to knock the NSIS crowd, but making non-standard Windows installers always results in a lot more work for the developer, and a more uncomfortable experience for the end user.
If you want to manually package the GTKmm runtime, see this link at gnome.org for more details (look under Redistributing). You can also silently run the GTKmm installer using the /S flag.