I have some code in Ansi-C, written for Unix, that I'm having trouble compiling and running in Dev-C++/MinGW.
Do you know of any tutorials or "helpful hints" in porting C code from Unix to MinGW? Things like which include files and libraries to change, which C commands need to be changed, etc. I haven't been able to find anything generally useful in my Google searching.
Thank-you for your help!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ANSI (or rather ISO) C code is ISO C code, and is by definition portable.
The ISO standard includes the language definition and the library specification. If the code does not compile and you are having issues with "include files and libraries" the chances are that you are using non ISO libraries. Tell us what they are, and we might help directly. The possibilities of what libraries you employed are almost endless, so you are unlikely to find a single source ho assistance.
The best approach is to understand what libraries you are using, what they do, and find the equivalent or identical library for Windows.
Note it is rather about Windows than MinGW. MinGW comprises of the GNU compiler toochain, but a set of Windows libraries and tools. Its standard C library is Microsoft's rather than GNU.
One of the most common library difficulties for example is the networking API. Whereas you might have code using teh BSD Sockets API, Windows uses the Winsock API. Winsock is based on BSD and very similar, porting the code is relatively simple.
The greatest difficulty in porting Unix/Linus code to Windows is the different processing model. Constructs such as fork() are very difficult to replicate directly in Windows, and you would have to redesign your code to work differently.
If not, perhaps you need to learn effective search strategies. If you use MinGW in your search that would probably not get you very far - it is too specific, the fact that you are using MinGW is largely irrelevant - MinGW is not analogous to UNIX - one is a toolchain the other an OS; consider "porting UNIX Win32" instead.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wayne, I haven't installed Cygwin because when I was reading about it, it sounds like code can only be run within that special environment. I can't just go to the directory in Windows, and double-click on the executable. (let me know if I'm mistaken) Also, I've been using Dev-C++ to develop all my code, and it seems like it might be troublesome to try to meld the two environments.
Clifford, thank-you for the links, I will examine them carefully. To address your points, the code I'm trying to port is purely computational (no network socket stuff), and the word "fork" does not appear anywhere in the code.
I think I've fixed the compilation problems. For example, they were using srand48 and drand48. I replaced them with srand and rand. And, it was choking on "getopt", so I added the include file unistd.h (after reading about getopt function at Gnu site). Other include files used by the code are: stdio.h, math.h, malloc.h, string.h, stdlib.h, and ctype.h
Do any of these raise red flags in your mind?
As for libraries, the only one in the make file of the code distribution was "m", so I tried using libm.a (comes with MinGW/Dev-C++ distribution), but that really freaked out the compiler/linker, so I dropped it.
The state of things at the moment is that the program is compiled, but bombs in run-time, getting hung up with some array of pointers to structures (yuk!). I'm hoping I'm just missing some include file or something easy like that.
Anyway, thanks again for your help, I really appreciate it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You do not need to be running in the Cygwin environment to run an application created within it. There are a number of applications that are out there that are distributed commonly that you would never know cygwin was involved with, other than they come with cygwin1.dll.
Compling under Cygwin does require that the application be linked with cygwin1.dll, which provides the Posix emulation capabilities. This has implications if you want to distribute the code due to the GPL.
Wayne
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> I can't just go to the directory in Windows, and double-click on the executable.
Yes you can. The Bash shell is useful for shell scripting and executing build and configure scripts that expect a Linux commend environment. That said, Cygwin is the spawn of the devil and in my experience causes more problems than it solves. Unless you are running VM software to isolate your Cygwin installation from any other GNU based tools you might used (like MinGW), I would avoid it like the plague.
>> For example, they were using srand48 and drand48. I replaced them with srand and rand.
Be cautious. If statistical rigour is required of your random number generator, the standard library implementations may well fall short. For example rand() has a range 0 to RANDMAX and in this implementation RANDMAX is a puny 32767 (i.e. a 15bit range). Also note that drand48() returns a double, rand returns an int. http://opengroup.org/onlinepubs/007908799/xsh/drand48.html
Here is a Win32 kludge to 'simulate' rand48() operation:
>> so I added the include file unistd.h
The MinGW implementation of unistd.h is not complete, it implements only those functions that have direct simple equivalents in Win32.
>> stdio.h, math.h, malloc.h, string.h, stdlib.h, and ctype.h
No need to explicitly link the math library, it is already a default library. This is basically everything declared in <math.h>. If it linked you have all you need.
>> but bombs in run-time, getting hung up with some array of pointers to structures
You should not assume that the original code had no bugs just because it ran successfully on a different target. On the other hand you may have introduced a bug in the port.
>> I'm hoping I'm just missing some include file or something easy like that.
Not likely (in fact not possible). If it compiled and linked all the dependencies must have been present. You will have to debug it I am afraid. Header files are not magic, they are (generally) merely source files containing declarations for code in other object files or libraries.
Make sure you compile with -Wall -Werror and -Wformat, and fix all warnings before proceeding. Code without warnings will be more portable, and fewer bugs.
After now reading various links regarding porting Unix to MinGW and checking that certain bad things are not present in the code (like "fork"), I've concluded that probably the code is a little buggy, and I need to go through it the old fashioned way (ugh).
But, I just wanted to thank Clifford and Wayne for their help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have some code in Ansi-C, written for Unix, that I'm having trouble compiling and running in Dev-C++/MinGW.
Do you know of any tutorials or "helpful hints" in porting C code from Unix to MinGW? Things like which include files and libraries to change, which C commands need to be changed, etc. I haven't been able to find anything generally useful in my Google searching.
Thank-you for your help!
I am curious, why are you using MinGW rather than say, Cygwin?
Wayne
ANSI (or rather ISO) C code is ISO C code, and is by definition portable.
The ISO standard includes the language definition and the library specification. If the code does not compile and you are having issues with "include files and libraries" the chances are that you are using non ISO libraries. Tell us what they are, and we might help directly. The possibilities of what libraries you employed are almost endless, so you are unlikely to find a single source ho assistance.
The best approach is to understand what libraries you are using, what they do, and find the equivalent or identical library for Windows.
Note it is rather about Windows than MinGW. MinGW comprises of the GNU compiler toochain, but a set of Windows libraries and tools. Its standard C library is Microsoft's rather than GNU.
One of the most common library difficulties for example is the networking API. Whereas you might have code using teh BSD Sockets API, Windows uses the Winsock API. Winsock is based on BSD and very similar, porting the code is relatively simple.
The greatest difficulty in porting Unix/Linus code to Windows is the different processing model. Constructs such as fork() are very difficult to replicate directly in Windows, and you would have to redesign your code to work differently.
Your Google search should have turned up these:
http://msdn.microsoft.com/en-us/library/y23kc048.aspx
http://msdn.microsoft.com/en-us/library/y23kc048(VS.71).aspx
If not, perhaps you need to learn effective search strategies. If you use MinGW in your search that would probably not get you very far - it is too specific, the fact that you are using MinGW is largely irrelevant - MinGW is not analogous to UNIX - one is a toolchain the other an OS; consider "porting UNIX Win32" instead.
Clifford
Thank-you for the replies, Clifford and Wayne.
Wayne, I haven't installed Cygwin because when I was reading about it, it sounds like code can only be run within that special environment. I can't just go to the directory in Windows, and double-click on the executable. (let me know if I'm mistaken) Also, I've been using Dev-C++ to develop all my code, and it seems like it might be troublesome to try to meld the two environments.
Clifford, thank-you for the links, I will examine them carefully. To address your points, the code I'm trying to port is purely computational (no network socket stuff), and the word "fork" does not appear anywhere in the code.
I think I've fixed the compilation problems. For example, they were using srand48 and drand48. I replaced them with srand and rand. And, it was choking on "getopt", so I added the include file unistd.h (after reading about getopt function at Gnu site). Other include files used by the code are: stdio.h, math.h, malloc.h, string.h, stdlib.h, and ctype.h
Do any of these raise red flags in your mind?
As for libraries, the only one in the make file of the code distribution was "m", so I tried using libm.a (comes with MinGW/Dev-C++ distribution), but that really freaked out the compiler/linker, so I dropped it.
The state of things at the moment is that the program is compiled, but bombs in run-time, getting hung up with some array of pointers to structures (yuk!). I'm hoping I'm just missing some include file or something easy like that.
Anyway, thanks again for your help, I really appreciate it.
You do not need to be running in the Cygwin environment to run an application created within it. There are a number of applications that are out there that are distributed commonly that you would never know cygwin was involved with, other than they come with cygwin1.dll.
Compling under Cygwin does require that the application be linked with cygwin1.dll, which provides the Posix emulation capabilities. This has implications if you want to distribute the code due to the GPL.
Wayne
>> I can't just go to the directory in Windows, and double-click on the executable.
Yes you can. The Bash shell is useful for shell scripting and executing build and configure scripts that expect a Linux commend environment. That said, Cygwin is the spawn of the devil and in my experience causes more problems than it solves. Unless you are running VM software to isolate your Cygwin installation from any other GNU based tools you might used (like MinGW), I would avoid it like the plague.
>> For example, they were using srand48 and drand48. I replaced them with srand and rand.
Be cautious. If statistical rigour is required of your random number generator, the standard library implementations may well fall short. For example rand() has a range 0 to RANDMAX and in this implementation RANDMAX is a puny 32767 (i.e. a 15bit range). Also note that drand48() returns a double, rand returns an int. http://opengroup.org/onlinepubs/007908799/xsh/drand48.html
Here is a Win32 kludge to 'simulate' rand48() operation:
double drand48(void)
{
double rv;
}
I stole it from here: http://code.google.com/p/electric-fence-win32/source/browse/trunk/tstheap.c - note that it carries none of the guaranteed or implementation requirements of the true rand48() function, but it may be good enough for your needs.
You might also consider using this: http://gnuwin32.sourceforge.net/packages/libgw32c.htm
>> so I added the include file unistd.h
The MinGW implementation of unistd.h is not complete, it implements only those functions that have direct simple equivalents in Win32.
>> stdio.h, math.h, malloc.h, string.h, stdlib.h, and ctype.h
Are all standard headers, here's a list on the main ones (C99 adds a few more): http://www.cplusplus.com/reference/clibrary/
>> so I tried using libm.a [...]
No need to explicitly link the math library, it is already a default library. This is basically everything declared in <math.h>. If it linked you have all you need.
>> but bombs in run-time, getting hung up with some array of pointers to structures
You should not assume that the original code had no bugs just because it ran successfully on a different target. On the other hand you may have introduced a bug in the port.
>> I'm hoping I'm just missing some include file or something easy like that.
Not likely (in fact not possible). If it compiled and linked all the dependencies must have been present. You will have to debug it I am afraid. Header files are not magic, they are (generally) merely source files containing declarations for code in other object files or libraries.
Make sure you compile with -Wall -Werror and -Wformat, and fix all warnings before proceeding. Code without warnings will be more portable, and fewer bugs.
Some more information:
http://www.opengl.org/resources/code/samples/sig99/advanced99/notes/node389.html
Clifford
Wow, thanks for all of that, Clifford!
After now reading various links regarding porting Unix to MinGW and checking that certain bad things are not present in the code (like "fork"), I've concluded that probably the code is a little buggy, and I need to go through it the old fashioned way (ugh).
But, I just wanted to thank Clifford and Wayne for their help.
The best way to do this is with a debugger. Unfortunately Dev-C++ does not have the best debugger.