I'm a bit stuck on trying to port my code from Windows to Linux. I created a Bluetooth based program, which seems to work in Windows well, that I need to get working in Ubuntu.
Unfortunately the computer with Linux on isn't mine, so I can't have any easy hacks using Wine or other massive compiler altering methods, I really need some advice on porting my code across so it'll be recognised and work in the different OS.
The computer does have code::blocks installed, which from what I understand is fairly useful in converting some things for cross-OS compiling, but I'm not getting too far.
The original code was written in Visual Studio 2013 and understandably it doesn't play nice in code::blocks. I'm getting a lot of 'can't find header' errors, but I don't think simply finding all the missing headers and copying them across will work (will it?).
I need some suggestions on the easiest, stand alone solution for my situation. By standalone I mean I want to get as much of the needed changes and libraries in my project, rather than change/install lots of things on the Linux machine.
I don't really know where to start and searches online don't seem to be too helpful.
Thanks!
First of all, I suggest you examine your Windows code, and use the PIMPL idiom (also here, here, ...) in your classes to isolate all platform-dependent code to separate windows and linux class implementations. Your main platform-independent class then will simply delegate to each implementation at compile time using preprocessor macros to include the appropriate platform implementation header and cpp files.
Beyond this, many runtime functions, as implemented in Visual Studio as either Microsoft-specific, or have been 'modified' and are no longer compatible or even have the same names as the standard ones you will find in linux. For these, you'll need to use a platform.h and platform.cpp file, with separate sections for the two operating systems, containing the missing functions in either macro-defined form (i.e. windows: strnicmp(), linux: strncasecomp() ), or write the missing ones yourself. Example:
// Linux section ...
#ifdef LINUX
#define strnicmp strncasecmp
#endif
The final work involved depends on how many windows-specific calls you have in your code.
Related
Say I developed a simple software using C++, and I want to distribute it for free. For simplicity sake assume it is some sort of GUI. Now when I compile it on Windows and run the .exe, it works as intended. However, the end user might have a different version of Windows then I do. So the .exe file may not run because of differences in machine code or instruction set (I think?) In these situation is it common practice to include the compiler to the end user so that the compiler is built and then my source code is compiled or do I use a cross compiler instead? Or how is it commonly done? Sorry for the stupid question.
So I made a c++ console game. Now I'd like to "release" the game. I want to only give the .exe file and not the code. How do i go about this. I'd like to make sure it will run on all windows devices.
I used the following headers-
iostream
windows.h
MMSystem.h
conio.h
fstream
ctime
string
string.h
*I used namespace std
*i used code::blocks 13.12 with mingw
& I used the following library-
libwinmm.a
Thank you in advance
EDIT
There are many different ways of installing applications. You could go with an installer like Inno or just go with a regular ZIP file. Some programs can even be standalone by packaging all resources within the executable, but this is not an easy option to my knowledge for C++.
I suppose the most basic way is to create different builds for different architectures with static libraries and then find any other DLLs specific to that architecture and bundle it together in one folder. Supporting x86/x86-64/ARM should be enough for most purposes. I do know that LLVM/Clang and GCC should have extensive support for many architectures, and if need be, you should be able to download the source code of the libraries you use and then compile them for each architecture you plan to support as well as the compilation options you need to compile to each one.
A virtual machine can also be helpful for this cross-compilation and compatibility testing.
tldr; Get all the libraries you need in either static or dynamic (DLL) format. Check that they are of the right architecture (x86 programs/code will not run on MIPS and vice versa). Get all your resources. Get a virtual machine, and then test your program on it. Keep testing until all the dependency problems go away.
Note: when I did this, I actually had some compatibility issues with, of all things, MinGW-w64. Just a note; you may need some DLLs from MinGW, or, if you're using Cygwin, of course you need the Cygwin DLL. I don't know much about MSVC, but I would assume that even they have DLLs needed on some level if you decide to support an outdated Windows OS.
I'm trying to compile a program on MacOSX that I originally wrote on a Windows OS. The program is a large C++ program with the OpenGL API among other things, totaling very many directories and files.
The compilation process at first had a problem with OpenGL for the Mac so I downloaded all the command line utilities of OpenGL for it to work. But as you might imagine, each C file within the OpenGL download had many preprocessors, each of which I in turn had to downloaded the dependencies for.
However, I have remaining one critical step: I receive a fatal error saying that windows.h file is not found. This seems something inherent to the Windows system (the windows.h file is nowhere to be found in my huge list of directories for the program), and the Mac does not seem to have an equivalent for windows.h (http://cboard.cprogramming.com/c-programming/96087-windows-h-mac.html).
Am I out of luck trying to compile this program for the Mac or can something be salvaged?
One thing you can do is create a dummy file called windows.h to satisfy the #include directive, then track down the missing typedefs, #defines, etc. one-by-one by looking at the compiler error log.
Windows.h is monolithic and includes about a hundred other Windows headers, but your program is not going to need all of those definitions. This assumes you are not using the Windows API directly, and only using simple things like DWORD. If your software is built using a framework like GLUT or GLFW that is entirely possible, but if you directly interface with WGL, you are going to have a lot of work ahead of you.
windows.h is provided by the Windows SDK, and implemented by the Windows OS itself.
You need to rewrite the program to not use Windows APIs.
Good luck.
You cannot get Windows.h for mac, it is Windows OS specific.
There are many alternatives to functions used in Windows.h on the other hand.
Too those who know how, this may be a stupid question, but I'll be asking it anyway because I need some pointers.
The library I'm trying to compile is the SPro toolkit for speech signal processing which is written in (for lack of a better description) Gnu C++
It's a library written for unix and I want to compile it in windows. As much as an object exercise in porting code from, as anything.
Toward that end I have installed code::blocks and a MinGW compiler. I read that I could also use cgywn and that this would be introducing a layer interpreting the gnu c before executing it natively, but let me leave that to the side for the moment.
The first issue I ran into was that the #includes need a little love - ok no problem with that.
But now I find that
scopy.c|462|error: 'SIZEOF_SHORT' undeclared (first use in this function)|
I also installed visual Studio C++ and get the same.
I gather that SIZEOF_CHAR, SIZEOF_SHORT, SIZEOF_LONG, SIZEOF_FLOAT and SIZEOF_DOUBLE would be declared, in a header or somewhere.
Unfortunalty I don't have any idea where, so have no idea what to include to have access to the definitions.
What should I include?
Do I need to define these constants myself as I am in a different environment?
Also I may be barking up the wrong tree, any help is appreciated.
#define SIZEOF_SHORT sizeof(short)
#define SIZEOF_CHAR sizeof(char)
Repeat for all other types.
Let's say I have a simple project in MSVC++ 2010.
All there is in it is main.cpp, its code being something simple like this:
// include macros
#define WIN32
#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/fl_ask.H>
// main function
int main()
{
// init window
Fl_Window *window = new Fl_Window(250, 250, "Derp Window");
// show window, run window
window->show();
int result = Fl::run();
fl_message("Goodbye...");
// release pointers
delete window;
// return
return result;
}
It's easy to make a Windows compatible version, all I have to do is set the mode to release and the build it. But, as I have recently found out, the generated .exe file would not work on a Mac or Linux OS. This surprised me because all I am using is plain old c++ and FLTK, which is cross platform.
So, my question is, how would I take this code and compile it in a way that it would work on a Linux OS, and the a Mac OS? Or, is it even possible to keep the same code and compile it in a different way so it works on another OS? If it is not possible, what would I have to change?
PS. The code is pretty straight forward but if you're wondering the #define WIN32 is there because without it, the compiler freaks out about a missing header file, something like "X/X11.h"
The code is compatible, but that doesn't mean the generated binary will be. By and large, this is never the case.
Compilers take your code and translate it into lower-level code that your specific architecture and platform can understand, and Windows is not the same as Mac. This lower-level code has basically nothing to do with C++, FLTK or the compatibility promises of either of them.
The analogy here is that driving a car on the left hand side of the road is, mechanically, the same as driving a car on the right hand side of the road (so let's ignore things like navigation differences and the fact that you're probably steering in different directions), so your knowledge of how to drive a car fits both scenarios identically … but that doesn't mean you can simply plonk your car on the left hand side of the road in France or the United States. You'd cause a pretty gnarly accident. When you apply your knowledge of driving a car to a specific environment you have to fit that around the local rules of the road.
You can re-compile the same code under the target environment, or use a cross-compiler.
If you don't have access to a Linux or Mac OSX computer, you have to cross-compile it. To do this you have to either find a existing cross-compiler, you download the source to e.g. GCC and build it your self. Do some searching from "cross compiler" (or similar) and you will find some easy to follow tutorials.
If you do have access to a Linux or Mac, then just copy the code and build it in that environment. Be careful with Linux through, as different distributions have different versions of some libraries.
And finally, there are environments such as Wine which will allow Windows programs to run on other platforms.
If you use FLTK, you need to include its headers on every platform you compile your program, not just WIN32.
The error message you get about not finding X11/X.h is either caused by missing compiler flags (see 1), prerequisites that need to be included first (see 2), or missing headers (see 3).
Use fltk-config --cflags to get the required compiler flags, fltk-config --libs for the flags you need to pass to the linker.
Doesn't seem to apply here, but you might encounter libraries that require it.
If you use Ubuntu or Debian, install the X headers by executing apt-get install x11proto-core-dev, but that shouldn't be required if you already installed libfltk1.3-dev (or some other version), as it should pull in all the required dependencies. If you use a different distribution, make sure you have the X headers package installed.
The problem is probably the #define WIN32. From what you describe, I would guess that the FLTK library is using this to conditionally compile its headers either for Windows or for Unix (X). So you'd need it defined when compiling for Windows, and undefined when compiling for Unix. The usual way of handling such issues is to add a /DWIN32 option to the compiler invocation when compiling for Windows. You'll probably also have to do something to get the right libraries.
And FWIW: it's perfectly possible to design the library so that the header files work for both systems, without any conditional compilation. And if you want conditional compilation, you should probably use the system's predefined symbols (_WIN32, for example).