Let's say I have an application which I compiled under cygwin, and I want to distribute that application without having the user to install cygwin. Would it be enough to package the executable and the cygwin DLL?
Things have changed. The Cygwin libraries are now under the Lesser GPL (v3), which makes it possible to bundle them with applications that fall under a wide range of licenses, from FOSS to proprietary.
What stands in the way is that the POSIX emulation in Cygwin takes things a little too far from the perspective of native Windows applications.
This is where my Cygnal project comes in. Cygnal stands for CYGwin Native Application Library: it is a drop-in compatible fork of Cygwin which changes, or in some cases simply re-configures, the behaviors of certain functionality in order to conform with native conventions of the Windows platform.
A basic "Hello, World" Cygwin program requires two libraries. A GCC run-time called cyggcc_s-1.dll and the Cygwin DLL cygwin1.dll. The Cygnal project provides a replacement for the latter. (A 32 bit build is available for download).
One glaring area of incompatibility between the Cygwin POSIX view of the world and Windows is path handling. The Cygwin view of the filesystem is through a fake / root directory, and its own internal "mount table" which provides spaces like /cygdrive, /proc and /dev. Cygnal does away with all that. Paths are Win32 paths. The current working directory behaves like the Windows current working directory. Drives are associated with current directories, and drive relative paths like D:foo.txt work under Cygnal. Under Cygnal, /dev and /proc are still available: they are accessed as the special prefixes dev:/ and proc:/. It is not permitted to chdir into these: that would not be native! Under Cygnal, if you chdir to D:\wherever then your current drive is the D drive, and the paths /foo or \foo refer to D:\foo. Cygwin's master POSIX root directory is gone.
Yet, with Cygnal, you can continue to use the POSIX functionality, making it possible to develop cross-platform programs that have less code that is switched based on platform, compared to maintaining a port using MinGW or Microsoft Visual C/C++.
For example: you can write a Win32 console application using VT100 codes and termios. The same code will run on Unixes. No need to use the Win32 console API on Windows and VT100/termios on a POSIX system.
Another example: for threading, you can just use POSIX threads. pthread_create to start a thread, pthread_mutex_lock to lock a mutex and so on. Your program doesn't need a portability abstraction for threads which translates to Win32 or POSIX; you just use the POSIX and that's it.
The uname function in Cygnal reports the sysname with a CYGNAL prefix rather than CYGWIN. By means of this, your program can tell that it's running on Cygnal rather than Cygwin (or any other POSIX platform). Thus you can make any necessary adjustments: for instance, if your program needs /dev/null, on Cygnal it can look for dev:/null instead.
Does your application actually need any Cygwin provided Posix emulation? If not, you can compile it with the -mno-cygwin flag and it won't depend on cygwin at all, but will be a native Windows application. Often, you only need a real shell (bash) to configure and build your application, but you don't actually need the Posix functionality of Cygwin.
Another alternative is MSYS + MinGW, which is a light-weight fork of Cygwin. This provides a compilation environment which produces native Windows apps by default.
A third option would be to use the MinGW compilers from Cygwin itself. They should be available via the normal Cygwin package manager. Then you would configure the project for a cross-compile using the MinGW compilers.
Normally, yes. Be sure to install the Cygwin DLL in a public location though (Windows\System32), this DLL behaves very badly when multiple versions of it are loaded on the same machine.
You could try to compile everything as static. That should allow you to run everything without the need of the the libs (since they are already in your binary).
But this will also mean that it might not work an all platforms if cygwin would need a different or newer dll.
Related
Libraries built with Mingw-w64 require those dll:
libwinpthread-1.dll
libstdc++-6.dll
libgcc_s_seh-1.dll
I wonder what's up with that, what each dll does? Especially libgcc_s_seh, is that structured exception handling? I thought mingw couldn't work with seh.
Why mingw requires to always bring those dll with your exe?
I wonder if I'm just wasting my time by not just using visual studio as a windows compiler. It's so bloated though, 9 gb for installation.
Especially libgcc_s_seh, is that structured exception handling? I thought mingw couldn't work with seh.
Newer versions of GCC (4.8+ if I'm correct) should support SEH on MinGW.
I wonder what's up with that, what each dll does?
They provide the runtime and standard library.
libwinpthread: PThreads implementation on Windows (Threading)
libstdc++: C++ Standard Library (C/C++ library functions etc.)
libgcc_s_seh: Exception handling (SEH)
Why mingw requires to always bring those dll with your exe?
Because your program uses them. If you write a program without threads, standard library and exception and any OS interaction you wont need them.
These DLL's bring everything you need to run your program. Btw. this is not a MinGW only thing, and happens on other systems / compilers too. Often you just don't note this because the OS already ships the libraries, eg. MSVC libraries are very likely on a Windows machine. Dynamic linking always requires some sort of library files, that are .dll on Windows and .so on Linux.
If you have it available on your system use ldd <your application> to see what libraries are dynamically linked.
You can install these MinGW libraries into the system libraries or somewhere where the OS can find it. This enables your programs to use it and you no longer have to ship it with every application (what avoids duplication).
On the other side another option is to static link them. Unlike dynamic linking, you don't need any DLL; on the downside is a increase of you applications size (as now the three libraries are baked into the exe now).
I wonder if I'm just wasting my time by not just using visual studio as a windows compiler.
This depends on your situation. But probably my answer will give you some more insight.
I have source code for a linux application. It seems I can compile it on windows with CygWin. My question is, after compilation, can I run it on Windows?
Depends totally on what APIs you use. If you stick to C standard library things, like <stdio.h>, <stdlib.h>, etc. then yes, you can just compile and run on either OS. Or for C++ apps, there is the Standard C++ Library, which any OS / development environment should provide.
If you use any OS-specific APIs, then of course it will not be compatible with another OS. There are libraries however, like APR that try to abstract out the OS-specific bits.
From a casual glance at the code you've linked to, it appears to not use any OS-specific APIs. However:
Note that this code requires the Gnu Scientific Library, http://www.gnu.org/software/gsl/
you'll need to get that library installed as well.
The simple answer is yes; if you can compile a Linux application with Cygwin, then the compiled application will run on windows. Cygwin provides windows implementations of many unix system functions and libraries.
Cygwin/mingw(http://www.mingw.org/) should have most of the tools you need to build the binary. Once the build succeeds, you can run the binary (only) on windows.
I have developed a small application in Qt Creator on Ubuntu 12.04 which I want should run on any other linux distro (mostly different versions of CentOS and ubuntu), just like any portable application on windows does.
I want to be able to simply share the binary file of the Application, and run the application.
I am able to successfully do this in windows, by just building the project in QT Creator and then putting the required libraries in the Application directory and then transfering them to other windows systems.
I searched all over and found out that I should be trying to build the project using LSB(Linux Standard Base) Compatibility, so that it runs on other linux distros. Is that the right way to do this?
I am very new to Qt and also to Linux (dont know much of Shell Scripting).
Thus, I dont know how I should proceed to make the Application LSB Compliant.
I have refered to, the following links:
Distributing Qt-based binaries on Linux and
Deploying Qt applications on Linux but have not beem able to understand what I am suposed to do.
I also found this question here which states a very similar situation as mine, but because I am a novice, I dont know how I should do this.
Moreover, considering that the first two articles were written 6 years back, shouldn't there be a simpler way to deploy Qt apps on the linux platform now?
I also saw something about static linking, is that the way to go?
Isn't there a way by which all of this can be done through Qt Creator itself?
If there is no hope of creating a portable Qt Application for Linux, then is there a way, say a shell script or something that would combine all the steps required to compile the Qt project on another computer and run it. Say, download Qt-SDK if not present, run qmake and make and then the newly compiled application, if not already there, so that the user can run the program just by running one script.
Your problem here is not the Linux Standard Base, but rather the presence or not of the specific version of Qt you need (or a later one).
Exactly like on a Windows machine, a user may have any of Qt installed, or they may not have it at all. On Windows it is easier to check for the presence of a certain version of Qt than it is on Linux, thus it is easier to write install tools that automate the experience.
To solve your problem there are a few ways:
Inform the user that your program requires a certain version of Qt or higher, and let the user handle the problem
Learn how to create packages for every distribution you want to target and create specific packages
Use a program like 0Install or Elf Statifier to create a package/executable containing all the necessary libraries.
The latter is similar to what many Windows and Mac programs do (they include every library they need within the installer), but it is not the preferred way on Linux, which relies heavily on shared libraries.
Making a binary application compatible with any other Linux distro is practically impossible since you will never know in advance which libraries are available in distro X, or what version of that library is available. Even among a single distro (e.g. Ubuntu), binary application are almost never backward-compatible, since anything built on Ubuntu 12.04 will have dependencies on versions libraries which are installed on that version of Ubuntu, and trying to run that binary on Ubuntu 10.04 will most probably fail simply because it doesn't have a recent enough version of glibc or some other necessary library.
However, the idea can be much more implementable if you limit yourself to a finite list of distros and versions of those distros. You can then know which libraries are available for those distros, and aim for the lowest common denominator. I used to maintain a binary application which had to support several distros (Ubuntu, Fedora, OpenSUSE, SLED, Mandriva), and the way I would do it is install the oldest distro I was targeting on my build machine. That way, the binary application would be linked to the oldest versions of the libraries available on those distros. Unless there's a new major version of such a library (which happens quite rarely, and even then, distros usually distribute the previous major version for a while for compatibility purposes), your compiled binary will then be compatible with all your targeted distros.
Therefore, the quick piece of advice I would give for your situation, use the oldest LTS version of Ubuntu which is still supported (10.04 at the moment) for your development, and you should be pretty safe for most recent popular distros. For the application you already developped on Ubuntu 12.04, you should have no problem simply recompiling the same source on 10.04. Understand that you will never however achieve 100% compatibility with a compiled C++ Qt application.
If Qt is not all that important to you, you could use a higher-level or interpreted language such as Python, Java, Perl or Ruby. With such languages, you can usually count on the language implementation already being installed on the target distro.
Deploy an application in Linux is a nightmare, luckily there are some solutions. Check this projects to build a portable binary with all their dependencies bundled:
http://statifier.sourceforge.net/statifier/main.html
http://www.magicermine.com/index.html
http://www.pgbovine.net/cde.html
Another solution is make a portable 0install package:
http://0install.net/
I recomend this solution. Personally I have been problems with the 3 first packagers.
Does NSIS support Linux and Solaris? I read somewhere that we can compile nsis script on Linux but cant execute the .exe generated on any other platforms but Windows. Can somebody put more light in this?
No.
See the NSIS feature list for more information ...
Portable Compiler
The NSIS compiler can be compiled for POSIX platforms like
Linux and *BSD. Generated installer
will still run on Windows only, but
this way they can be generated without
Windows or WINE.
You can compile installers on POSIX and Windows systems, but it always produces a Win32 PE file that only runs on Windows (And maybe under WINE on *nix)
Check the NSIS manual for more info
The installer systems for Windows and Linux are completely different.
Whereas Windows' only contribution to a software management system is one registry entry pointing to the uninstaller, Linux has a full working software management system. There are apt, yum, pacman and many more out there, which are supporting many more features and possibilities including automatic execution of scripts and pulling in/installing dependencies. If you have a cross platform application you wanna share, you're either stuck with creating a tar-ball, or you learn how to build deb/rpm etc. packages.
Linux and Windows are not binary compatible, so you can't do that.
But, most of the windows binary installer could able to install at WINE
Is there anyway to write dlls in linux?
Do I have to install windows to write dlls in linux? Right now one of my courses requires me to write a dll for this.
You should take a look into 'shared libraries'
http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html
Lots of folks are getting near the right answer but not providing it: gcc can generate win32 PE/COFF files without problem, and of course can always build as a cross compiler on any platform it can target. The binutils port targets windows .exe and .dll files natively, and there's a "dlltool" utility for handling the edge cases where Unix and Windows linkage metaphors are different.
Additionally, the "mingw32" project provides a set of link libraries and header files for building C applications against the win32 API. These likewise install just fine on any Unix.
Here's a site I turned up after a quick google with instructions for building the toolchain.
Not really. Building any kind of executable intended for OS "A" while using OS "B" is a process commonly known as cross-compilation. In this partciluar case, you would need a cross-compiler running on Linux, but targetting Windows. I don't know any vendor selling such a product.