I’ve got an app that creates a child process to execute via CLI a compiled C++ library file. What is the best/most portable way of shipping my app with this library? I just need to ensure the compiled C++ code is available on the user’s system and that the executable is compatible with their system.
C++ is compiled for each platform (Windows, macOs, Linux). So you need three different distributions:
Windows - lowest common version (for example Windows 7). You also need to require or include the C++ redistributable for the compiled library.
Linux - most use gcc, so again the lowest common version. No redistributable required.
macOs is similar to Linux.
Each platform supports multiple compilers and IDEs. It’s down to personal choice.
Related
I want to learn C++ and I want to know if using Microsoft VC++ will tie me to Windows. I specially need my project to also run on Mac. My projects are all Class libraries and have no dependency to UI. They are just calculations or file/network IO.
I really like working in Visual Studio and Microsoft way overall. So my priority is to go VC++ unless it makes painful to build cross platform apps for Windows and Mac. I mean at the compiler, libraries and language level. I don't want my parallel app to fall apart on certain platforms.
I personnaly use Visual Studio to build my code on Windows and other compilers to build the same code on other platforms (Mac, Linux, Android...).
To be sure you don't get locked with Windows, make sure (at least, it's not exhaustive):
You don't use any win32 API (prefer cross plateforme libraries like boost for instance for network, file system access...)
You don't use 3rd party libraries only available for Windows
Don't use CString, or anyother Microsoft class. Prefer STL.
Be careful with file system case sensitiveness too! (#include "Foo.h" while file is "foo.h" on disk will work on PC, not under Mac/Linux). Prefer naming ALL your files in lower case.
...
You may want to have a look at CMake. This tool can help you generating compilation project file for the same source to be compiled on different plateform. Then, you can generate vcproj/sln files to compile your code with Visual Studio on Windows, MakeFile(s) to compile it under Linux and XCode project files to compile it under MacOS. If somewone wants to compile you code under Windows with another compiler than Microsoft, it's also possible!
Also note that recent version of VS (2015) propose to compile for other targets that Windows (at least Android). But never tried that.
The compiler itself is pretty standard confroming by know (if you turn off the extensions) and more importantly, you can use the clang frontend (which is the default compiler on Mac) directly from within VS2015, so it is definitvely possible to write cross-platform code in VS (although it's certainly easier to use Windows specific constructs than it where if you'd use e.g. cygwin).
However, the windows API for network I/O is different from the one for Mac, so you should probably use a corssplatform library like boost asio for that.
As far as multithreading is concerned, you can do it in a standard and portable manner using the standard library's functions, classes and synchronization primitives, but the past has shown that they are often not the most efficient way to go. However, in most situations you'll want to use a more highlevel library for parallel programming anyway. The default on Windows is the PPL which is - I believe - not cross-platform, but there are other libraries you can use
Finally, you can use VS to remotely build your applications on Mac or Linux PCs using their local compilers and libraries. However, I don'T know, how well that works in practice.
I have no experience with Linux, so this question might seem weird.
I am trying to use a c++ toolbox which has been developed on Debian GNU/Linux Lenny. According to the authors it should work on any recent Linux distribution. However, I need to import it into Visual Studio on Windows.
I have no idea how to get this package configured and built on Visual Studio. I see that there is a "configure" file in the package, but I don't how to use it on Windows. Any help would be appreciated.
You can use either MinGW or Cygwin to mock a *nix system enough to build most *nix software. The configure script is generally a (*nix) shell script which will check to see what interfaces and libraries are available to the application during compilation.
Depending on the library you may not be able to use it outside of a unix library, especially if the library depends on the POSIX (*nix) APIs beyond the very small set which Windows provides.
From your information the package is meant for linux.
This means that if the package contains precompiled code (such as .so or .a - shared libraries / static libraries)you will not be able to run it under windows no matter what (make abstraction of Linux simulated enviroments, I believe you want to run it on a Windows environment).
If the package contains only sources, then you can include the package inside your solution (I would personally go with a static library approach) and try to compile it. You will get some errors when linux specific headers are included (for example linux threading headers).
After finding the windows equivalent for those functions you will be able to compile and use the package on windows as well.
You basically have to do a manual port.
I've got new task to research the way of development C++ cross platform (Mac/Win) utility for our internal needs.
I've developed for 7 years using different "pink" languages like C# , Java , Managed C++.
But in this task , the requirement is to support Mac , and .NET that is running on Mac , is really pain (Know this from other guys who did used this).
So I've started to think about C++ if it's possible to use C++ for Cross platform development.
The application will no contain any GUI , but will contain a lot of System API calls , and a lot of business logic analysis.
Is there possible some library allowing to achieve such kind of Task ?
Is it possible to do at all ?
Yes, you can write standard, ISO C++ and run the programs on both platforms.
When you need to implement some functionality using platform specific APIs (e.g. using Win32 on Windows and POSIX APIs on Mac OS) then what you do is write your own wrapper functions that abstract away the platform specific details, and then use that wrapper in the rest of your program.
Tools like CMake will allow you use Visual Studio to build the program on Windows and Xcode to build on the Mac without having to manually manage separate Visual Studio and Xcode project files.
If I understand your question properly, the only thing you need to develop cross platform c++ is to get the right compilers. You could use GCC on both platforms or even use 2 different project files for visual studio and xcode. That's up to you. Personally, I prefer GCC.
Regarding code itself, it depends on what you do with it. STD is available on both platforms (std::vector, std::string, etc) so code should compile properly on both platforms.
Edit: Btw, most platform specific stuff are available through open source code (like boost though I personally don't like boost that much). If needed, you could even look at other open source projects that are cross platform (ogre3d, etc).
I have a C++ eclipse project that I would like to easily compile In Windows and OSX.
The project is currently using an automatically generated makefile.
The libraries that I need vary depending on the platform.
In osx I'm using the CoreMidi, CoreAudio, and CoreFoundation frameworks.
In Windows I'm using the winmm.lib and multithreaded libraries.
What's the simplest way to link different libraries/frameworks depending on the current platform?
I'm currently using the gcc toolchain on OSX. Should I start using the cross compile toolchain?
Should I have two projects. One for working in windows, and one for osx, checking them both in to version control?
Should I write a custom makefile instead of using the automatically generated option that has different g++ arguments depending on the platform?
I personally had the same goal for a project and came to the conclusion the Qt framework was the best thing for me. It handles multiple languages, unicode strings, XML, network communications, native looking user interfaces, console applications: it can do an AWFUL lot.
However, as Paul pointed out, you really have to plan it from the start.
Qt does a good job of abstracting the platform away (in a module called QtCore) allowing you to write vanilla C++ code, or you can chose to include some Qt C++ language extensions which a Qt helper application called the moc (meta object compiler) creates vanilla C++ from, which can then be compiled by most common C++ compilers.
It also has a nifty cross-platform makefile generator called qmake which works on project files to create normal make files for the platform its running on.
Off the top of my head at least Windows XP & 7, OSX 10.4, 10.5, 10.6 are supported currently. But note that OSX Lion is (as of writing) not officially supported but I suspect it will be in the next release.
Based on your description, I am not sure you can easily make it cross-platform. Even without using third-party library, you have to provide separate code for osx and windows. Most of time, they design the system as cross-platform first. It's really hard to make an existing project on single-platform to cross-one. If you have the cross-platform requirement, you'd better design in that way first and rewrite from scratch.
Even though Eclipse can run fine on both OS X and Windows, it is not designed to be used in this way.
The best way to do it is to use separate IDE projects for each platform. This this is the easiest way to have unique compilation settings for multiple platforms.
Yes, you can use two eclipse projects. Alternatively, it's not unusual to have a X-Code project for OSX, and a Visual Studio Project for MS Windows.
I have some question about cygwin :
Can I use Cygwin develop socket based code?
Does Cygwin have read() and write() functions that work with file descriptors?
Can I use Pthread library in Cygwin?
Does code that compiles in Cygwin also
compile in Linux without any change or with little change?
Will an executable file that built by
Cygwin run in Linux ?
Why does Cygwin not need the linker
option -lpthread when I use pthread library?
why in #include <iostream> don't I need to use using namespace std; ?
Can I work with QT in Cygwin? If so,How?
Can I boot my Linux in other
partition with Cygwin and use it?
Can I access the other partition
that is EXT3 in Cygwin?
On 1:
Yes. Socket libraries are shipped with Cygwin - many socket based apps such as web servers are included in the base distribution.
On 2:
Yes. I think all of the 'section 2 and 3' system calls in the GNU C runtime and library are implemented by the cygwin runtume. You can check this in the man pages that come with Cygwin. A list of system calls and std lib calls implementd by Cygwin can be found here.
On 3: Yes. Pthread is included in Cygwin. The list referred to in the link above mentions pthreads as well.
On 4: Anything built against GNU libraries should work with little or no change between Cygwin and Linux (assuming there are no dependencies missing on Cygwin). Depending on CPU architecture you may have to worry about word alignment, endianness and other architecture-specific porting issues, but if you're targeting Windows and Linux on Intel your code would have few if any porting issues arising from CPU architecture.
On 5: Cygwin will build a program against its own shared libraries by default but GCC can cross-compile to target other platforms. You could (in theory) set GCC up to cross-compile to any target supported by the compiler. There are plenty of resources on the web about cross-compiling with GCC, and I don't think the process will be materially different on Cygwin.
Note that Cygwin binaries will not run on Linux - or Vice-versa. You will still need separate builds for both.
On 6: Not sure - at a guess it's included in the standard runtime, perhaps because it was necessary to wrap the Win32 threading API for some reason.
On 7: Don't know - it's probably the same on g++ on all platforms. Apparently a compiler bug. Dan Moulding's Answer covers this in more detail.
On 8: Yes. IIRC QT is available in the standard builds and it will certainly compile on Cygwin. As with Linux/Unix, QT on Cygwin uses an X11 backend so you will need to have an X server such as XMing running.
In order to avoid the dependency on an X server you may want to build QT apps against the Win32 API,. It is possible to do this with MinGW, which is a set of header files and libraries to build native Win32 apps with GCC. MinGW can be used from within a Cygwin environment (an example of GCC on Cygwin cross-compiling to a non-Cygwin target) and the installer from cygwin.com gives you the option of installing it.
MinGW is quite mature; it has all of the 'usual suspects' - libraries and header files you would expect to find on a Unix/Linux GCC development environment and is very stable. It
is often the tool of choice for building Win32 ports of open-source software because it is (a) free, (b) supports the libraries used by the software and (c) uses GCC so it is not affected by dialectic variations between MSVC and GCC.
However, these dialectic variations in the language and available libraries (for example MSVC doesn't come with an implementation of getopt) mean that porting programs between MinGW and MSVC can be quite fiddly. My experience - admittedly not terribly extensive as I've only done this a few times - is that porting applications between MinGW32 and Linux is easier than porting between MinGW and MSVC. Obviously apps with non-portable dependencies such as Win32 specific API usage would require the dependent components to be re-written for the new platform but you'll have far fewer problems with differences in the standard libs, header files and language dialect.
QT does a fairly good job of providing a platform abstraction layer. It provides APIs for database access, threading, I/O and many other services as well as the GUI. Using the QT APIs where possible should help with portability and the Unix/Linux flavoured libraries that come with MinGW mean that it might give you a good platform for making applications that will port between Win32 and Linux with relatively little platform dependent code.
EDIT: The qt development packages in Cygwin are:
qt4: Qt application framework (source)
qt4-devel-tools: Qt4 Assistant, Designer, and Linguist
qt4-doc: Qt4 API documentation
qt4-qtconfig: Qt4 desktop configuration app
qt4-qtdemo: Qt4 demos and examples
You'll probably also need gcc4-g++ and some other bits and pieces. This listing on the cygwin web site has a list of the packages.
"Yes" to all of those except 5. You'll have to build your executables separately for Linux, but that should be straightforward since the answer to 4 is "yes".
Make sure you install all the development headers you need on both platforms.
Yes, Yes, Yes, Yes (if you write it carefully and don't use anything specific to cygwin), No.
On 5: it may be possible to cross-compile from Cygwin to Linux, I really don't know. If it is, then technically some executables "built by Cygwin" would run on Linux. But Cygwin executables won't run on Linux.
1-4: The answers to these are all "yes", because all of these features you are asking about are part of the POSIX standard. Cygwin is basically a POSIX layer for Windows so, naturally, Cygwin includes all of these features.
5: No, Cygwin binaries will not execute under the Linux kernel, because ultimately the code generated by Cygwin is Windows native code. It will link with the usual Windows DLLs (like kernel32.dll), whereas Linux does not even have a notion of DLLs (it has shared objects which are similar, but different). More importantly, executables built under Cygwin will be in the PE format, but Linux generally uses the ELF format for executables. You could, of course, do cross-compiling under Cygwin, and thereby generate native Linux executables, but it doesn't sound like this is what you are looking for. Also, compiling a new version of GCC to use as a cross-compiler under Cygwin is probably no trivial task.
6: GCC under Cygwin doesn't require use of -lpthread because all of the pthread code under Cygwin is in cygwin1.dll which is always linked in by default.
7: This is a bug in GCC (on all platforms). It has been around for a long time and will probably never be fixed.
8: ConcernedOfTunbridgeWells did a great job of explaining this, so there's not much left for me to say. However, it's worth noting that Cygwin has the X.org X Window System in its package list. With Cygwin 1.7.x, setting it up and using it is a breeze and it seems pretty rock-solid. If you want to use Qt with X, I'd recommend using Cygwin's X server.
In response to #7, the version of the C++ compiler that you have is probably out of date. If you don't need linux/posix portability, I'd switch to the non-cygwin MinGW GCC compiler - you can get 4.4.1 at http://tdragon.net/recentgcc/
Regarding 6, you don't need -lpthread because Pthreads support is part of the Cygwin DLL.