Here are a few lessons learned from porting a numerical library recently from Windows/Visual C++ to Linux/
Some of our code only runs on Windows, and only needs to run on Windows. Our first thought was to put
#ifdef WIN32 directives around that code. Clift Norris came up with the clever idea of using
#ifndef EXCLUDE_WINDOWS_ONLY_CODE instead. That way we could do a preliminary test of the portable subset of the code while still working on Windows where we’re more comfortable. Also, by not referring specifically to 32-bit Windows, we’re OK moving the code to 64-bit Windows.
Visual C++ does not require source and header files to end with newline characters, but
gcc does. We got hundreds of warnings of the form
warning: no newline at end of file when we first attempted to compile our code on Linux. Apparently there’s no
gcc switch to turn this off, and it may not be prudent to turn it off if you could. As I understand it, Visual Studio inserts a linebreak after including header files, but
gcc may not and so
gcc needs to issue a warning in this case while Visual Studio does not. We copy our source tree to a Linux box then run the following Python code on that box to insert the extra newline characters when needed.
import os # List of directories of files to add newlines to. # Script must be in the same location as these directories. directories = ["Banana", "Apple", "Peach"] for dir in directories: for file in os.listdir(dir): if file.endswith(".h") or file.endswith(".cpp"): path = dir + "/" + file handle = open(path, "r") slurp = handle.read() handle.close() if not slurp.endswith("n"): retcode = os.system("chmod +w " + path) if retcode != 0: print "chmod returned " + retcode + " on " + path else: handle = open(path, "a") handle.write("n") handle.close()
There were several places in our code where a variable was deliberately unused but retained in a function signature. Suppose a function has signature
void foo(int a, int b) but
b is unused. We had usually handled that by making
b; the first line of the implementation. That would suppress unused variable warnings in Visual C++, but not in
gcc. When we changed the function signature to
void foo(int a, int /* b */), that made both compilers happy.
We started out using autoconf, but that was overkill for our project. Our build process became two orders of magnitude simpler when we switched over to a crude, old-fashioned
make file. After porting the library to Linux, we built it on OS X without any issue.
This wasn’t an issue for us, but a potential problem when moving numerical code between Unix-like systems is that the function
gamma computes different things on different systems. On Linux it computes the logarithm of the mathematical gamma function but on OS X it computes the gamma function itself. See the last two paragraphs of how to calculate binomial probabilities and Thomas Guest’s comment on that post for a full explanation.
This library had been ported to Linux years ago, but nobody used it on Linux and so development continued only on Windows. When we first ported the code,
gcc and Visual C++ seemed to have incompatible requirements, especially with templates. The more recent port described here was much easier now that both compilers are more compliant with the C++ standard.
3 thoughts on “Porting Visual C++ code to Linux/gcc”
I am starting a project to do exactly the same thing. I wonder whether you can provide some help. Please contact me via email and let me know of your phone #.
Forgot to mention, in fact, we are hoping to hire a consultant to help us out. We can negotiate a per diem rate.
many thanks and please do email me.
Jane, thank you for your comment. Sounds interesting. I just sent you an email, but I also wanted to say something here in case the email didn’t go through.
Here’s my contact info.