Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I need to implement some graph partitioning algorithms for my thesis. I have mostly Windows experience. I would like to know if it is hard to migrate c++ console program to Linux. I want to program it on Windows but I want to test and compile it on Linux as well. It will be pure cli application, with no use of windows APi or anything. I just need to use some external libraries. Specifically GNU linear programming kit and GNU scientific library GSL. I found out, there are windows versions of these libraries, what does it mean for me?, should I compile it on Windows with windows version package and on Linux with linux package. I would like someone to bring a bit clarity to this, I am really not very experienced programmer, so any advice will help. Also I would like to ask, if there is diference if I use Visual Studio for programming or some other IDE in matter of portability issues. Thanks in advance for any help.

share|improve this question
Just to clarify, you're talking about a command-line program written in C++, not C++/CLI, right? –  Mat Apr 29 '13 at 7:17
If this is a pure command line tool you still need to understand the difference between managed and unmanaged code. If your original windows program relies heavily on managed code (search for gcnew) then it will be rather tedious to migrate. –  Thomas Apr 29 '13 at 7:21
Please, do not use "c++ cli" abbreviation for command-line interface c++ application (if we all understood you correctly) because C++/CLI is almost "official" name for managed C++ code on Windows. Use "C++ console" or something similar instead. –  SChepurin Apr 29 '13 at 15:29
@SChepurin C++/CLI is the official name of the managed/.NET-flavored C++ Microsoft offer. –  Tamás Szelei May 25 '13 at 8:23
add comment

2 Answers

The first thing to remember is that, although C++ source code can be ported between Linux and Windows, the compiled binaries can't be exchanged (at least not without using emulation software).

To create a portable application, your best option is to stay with standard C++ code and portable libraries. For the libraries, you can either build them yourself from source or you can use pre-built versions. In the latter case, you should make sure that you install the same version of the library on each platform to avoid hitting incompatibilities due to the different versions.

To ensure your code stays portable and you don't accidentally start using compiler-specific constructs, I would advise you to regularly compile your code for both Windows and Linux. That way you will get an early warning instead of having a pile of work at the end.

share|improve this answer
add comment

Note that you can cross compile using GCC, with the right flags and compiler options, and an install of mingw, you can compile Windows binaries on Linux (obviously you won;t be able to run them on Linux unless you install wine)

For a command line app, you should be ok - it depends how many Windows-specific system calls you make that will have to be replaced with Linux equivalents, though there are a few cross-platform libraries that might support these calls.

For cross platform development If you are looking for a cross platform IDE, you'll need to dump visual studio for one of the other ones. For C++, there's Qt Creator or Code::blocks both of which work well on Windows as well as Linux.

share|improve this answer
You don't need to dump VisualStudio at all: you can code using whichever editor/IDE you are comfortable with, and simply compile on other platforms. CMake is a fantastic tool in this regard. –  Tibo Apr 29 '13 at 12:26
@Tibo: I guess the OP meant it the way I changed his answer. –  Doc Brown Apr 29 '13 at 14:54
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.