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.
Related
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.
As per my knowledge, windows uses .lib and .dll extension for libraries and linux uses .a and .so. I am working on a project in ubuntu for manipulation with jpeg image files. so i want to know if these libraries can be used interchangeably in linux and windows? for example if have created example.so library in ubuntu and now i want to use it in some compiler in windows...
If you're planning on running under Wine, then yes.
Otherwise the chances are small. Windows DLLs will most probably use Windows APIs not available on Linux. Even if they're not the DLLs are built for use with compilers running on Windows.
Why not use imagemagick? http://www.imagemagick.org/script/index.php
Hi I am new to android NDK Devlopment.I downloaded Android NDK 4 for windows.I read through the docs.But i am not clear with it.
First thing is that,I want to develop the native file which may be c 0r c++.I think Using Cygwin will come to play.I dont have any idea or how to use cygwin .From the Docs i just read Cygwin is required for Windows platform.Apart from it ,i dont have any knowledge about it.
Not yet started with NDK Concepts.Help Required
Cygwin is a way to make Windows support some linux functionality. If you install cygwin on your windows machine you'd be able to run some linux software on windows (you'd have to recompile it especially for cygwin though). You can find it and more information about it here. There's also a good explanation at the wiki page here.
If the Android NDK needs it I suppose the Android NDK needs some linux functionality or tools to work properly. The other option might be to install Linux on a machine and run the Android NDK on there, it might be better since I assume Linux is the native environment for Android NDK development.
Since you're saying that you're a bit unclear about the NDK, you should probably be aware that as far as I understand you can not build a whole Android app using it, you can only develop bits of it, you will still need to develop at least part of the app to run on top of the Dalvik virtual machine, which, as far as I know, means that you'll have to write that bit in Java. In general I think that you should develop Android apps only in Java unless there is a specific reason to build certain parts of it using the NDK.
From wiki:
Cygwin (pronounced /ˈsɪɡwɪn/,[2] SIG-win) is a Unix-like environment and command-line interface for Microsoft Windows. Cygwin provides native integration of Windows-based applications, data, and other system resources with applications, software tools, and data of the Unix-like environment. Thus it is possible to launch Windows applications from the Cygwin environment, as well as to use Cygwin tools and applications within the Windows operating context.
Cygwin consists of two parts: a Dynamic-link library (DLL) as an API compatibility layer providing a substantial part of the POSIX API functionality, and an extensive collection of software tools and applications that provide a Unix-like look and feel.
So, Cygwin is a set of tools which allows you to emulate a unix-like (or linux) environment on your windows machines.
The NDK is the Android Native Development Kit. It allows you to write parts of your application in native code (C/C++) and integrate them into your application. Your application still runs under the Dalvik VM but it can load shared objects creating using a cross compiler. The NDK contains all the necessary tools and build scripts to generate native code binaries. It's an advanced concept and one you should probably wait on until you fully understand the architecture.
The reason why it requires Cygwin (or some flavor of linux) is because it uses GnuMake and other linux tools such as awk or Nawk. These tools are not available (or are really hard to use) on windows platforms, hence the need for at least Cygwin (though I would advise you do yourself a favor and just install linux).
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.
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.