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.
Related
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.
Is there some sort of documentation for what kind of headers you can include in c++ files when writing programs for Raspberry Pi or linux in general?
For instance I found this great guide on how to access the SPI bus from the Pi using c++ (http://hertaville.com/2013/07/24/interfacing-an-spi-adc-mcp3008-chip-to-the-raspberry-pi-using-c/)
I was able to take the code and apply it to my situation and was succesfully able to talk to an nRF24L01+ RF module and I am able to command the chip etc.
But as I started trying to investigate what the code does (because I like to know how code that I get from the internet works) I get lost very quickly. For instance how did the author of that code know to include the header files he did:
#include <unistd.h>
#include <stdint.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/spi/spidev.h>
#include <stdio.h>
#include <errno.h>
#include <stdlib.h>
#include <string>
#include <iostream>
I know what the ones such as "iostream" do but I thought I would approach it by Googling those header file names such as ("unistd.h") but no luck. I found lots of info but none pertaining to the Pi, and the little bit I did only started referencing other header files and code. Is this too much to try and learn, like would I effectively be trying to learn the linux kernel? Are there any good books for this type of stuff?
And back to my original question is there any kind of online (or offline for that matter) documentation for what header files you can include in your c++ projects on the Pi and what functionality they all add?
I found this (http://www.cplusplus.com/reference/) which has the standard files, but how do you know about all the non-standard header files and corresponding functionality?
All thoughts and help are appreciated, thanks!
Wesley
Edit 1
Here is the image showing the output of the "ls /usr/include" command:
TL/DR:
I've tried to have a general introduction to this topic below. If you are a more hands-on type and want to skip the wall of text, jump to the end. There are some tutorial links down there. Jump in -- getting stuck leads to the kind of questions Stack Overflow is best at.
Headers vs Libraries in C/C++
There is an important distinction to be made between header files and libraries in C++. Header files are the visible thing in your code, since they are what you actually mention in an #include statement. In most cases, though, the headers you are including correspond to libraries installed on the system.
As a practical matter this is important for two reasons:
You don't generally install "headers" on your system, you install libraries that happen to come with headers. There are a small number of header-only libraries that are exceptions to this rule, but usually you have a binary library somewhere that the header is facilitating access to.
The #include statement is only half of the story. There is usually a corresponding compiler option where you need to specify that you want to link against a particular library. In an IDE, this will be buried in the project options somewhere. For a command line compiler, this will be a switch that you pass to the compiler on the command line or (more commonly) in a Make file or similar.
That second point is actually true of your standard libraries like iostream or stdio.h, but these are backed by the standard C or C++ library that is linked in by default.
Linux in general
Most linux distributions will come with a package manager of some kind. There are a number available (Ubuntu uses Apt, Redhat uses yum, Arch has pacman, Gentoo has portage, etc.) The actual manager used is one of the defining properties of the distribution. Documentation will be easy to find on your Distro's web page. This is a very important tool to understand.
With the exception of the various C/C++ and Posix standard headers, the headers you have available for use are a function of the libraries you have installed on your system. This is important to understand because the list of available headers consists of all the available libraries on the internet, not just the few that your system happens to have installed at the moment.
Each library will generally be wrapped up as a package for your linux distro. When you locate a library that you want, you install the corresponding package. This will give you the required header and library files.
It actually isn't often useful to go looking for the libraries and headers on your hard drive, but if you are curious, header files conventionally end up somewhere in one of the following directories (or a subdirectory inside these)
/usr/local/include
/usr/include
Libraries will mostly be found in
/lib
/usr/lib
/usr/local/lib
These will have cryptic names that include their version number, and a more general (still cryptic) name that symlinks to the one with the specific version number.
Some distributions have separate "development" versions of libraries that include the headers, and only install the runtime files by default (ie the files your users need to run your program). If your distro does this, you'll need the development package to write software with that library.
When you have decided on what functionality you require, you generally go looking for a library that will help you accomplish that task. You can ask around on forums, or just google for them.
Device drivers in the Kernel
Most libraries will interface with a device through a device driver. In linux, device drivers are compiled into the kernel, or present as modules that are loaded into the kernel. Your Pi distribution will hopefully have come with all the required drivers for the hardware present. If not, you'll need to obtain a kernel module or recompile your kernel to include the required driver. The modules and appropriate scripts to load/unload them are generally available as packages for your distro, just as libraries are.
It is possible to write software to talk to a driver directly. This is a VERY broad topic. Your best bet is to pick a device (ie I2C, SPI, etc) and google for a tutorial for interfacing with that device on the Pi specifically.
This tutorial addresses the basics of writing a loadable module. It would be a good place to start if you want to write your own SPI driver.
This is a good place to go for a general kernel overview. It will help you understand what is available, how to get a copy of the kernel source, etc. This is also good knowledge to have if you want to write a driver. It is also a place to learn how to get your code submitted to the kernel, if you develop something new.
Finally, writing your own device drivers is possible, and isn't something to be scared of. The details of this topic that could fill a book, though, so it is something to google when you are ready to try it.
Linux on the Raspberry Pi
The first thing to understand about the Pi is that it is in most ways no different from a PC running linux. Any general information you find about systems programming for linux on a PC will apply equally to the Pi. The only caveats are that the processor architecture is different (ARM, vs Intel/AMD), and the Pi has a few hardware items (like I2C, SPI and GPIO) that are not common, or at least not commonly interfaced with, on the PC.
There is actually more than one linux distribution available on the Pi. These are usually derived from common PC distributions -- Ubuntu derived distros are most common. You'll want to locate the website for whichever distro you have.
If you try to install things outside of your package manager, you'll need to be careful to get libraries compiled for the ARM processor (or source libraries that you compile yourself). There are a few exceptions, but the vast majority of open source libraries should be usable on ARM.
This looks like a promising library that might be a good starting point.
This looks like a good GPIO (General Purpose Input/Output -- ie, pins you can toggle) tutorial.
This leads to some some SPI sample code.
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.
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).
I am writing an application that I would like to release binaries for on Mac, Windows, and Linux. I have code that compiles under Mac and Linux, but under Windows, it does not.
This is because of Windows lack of a strcasecmp. I've read a little bit about how I can create some sort of header to wrap my code, but I don't really understand this concept too well. I've worked on the code on my Mac with just vim and make, but now I'm trying to switch it all over to Visual Studio.
Is there some way I can set my project up to include Windows wrapper headers when I'm building on Windows, but omit them when I'm building on my Mac or Linux box?
This problem is really giving me a headache and I'd appreciate any suggestions!
You could do
#ifdef WIN32
#include <windows_specific_header.h>
#else
#include <other_header.h>
There is also an MS Visual Studio-specific macro: _MSC_VER, so
#ifdef _MSC_VER
would also work here.
There is also WINVER define in windows.h.
configure my project to generate platform independent code
That is a bit of an odd phase, so I'm not sure that I'm aswering the right question, but here goes:
You have to write platform independent code.
Do one of these:
Write to a cross-platform framework (i.e. QT)
Only use library functions that are available on all your targets
or
provide wrappers to fill up any gaps in the library for on (or more) targets
Boost libraries are designed to be cross-platform. In particular, if you need to manipulate strings, you'll probably find what you need. And it will be cross-platform without having to deal with it yourself. See there to get a glimpse of what's available.
maybe you can consider compiling your code with MINGW32 on windows.