I was recently tasked with performing a feasibility study based around switching from using DOS to Linux for use as an OS to run our industrial control software (developed internally). In a nutshell I have been restricted to using Ubuntu 8.04 (with a vendor supplied kernel upgrade providing drivers for the hardware on the board). As this is no longer supported I am unable to update or install software meaning that I am stuck using gcc version 4.2. I want to be able to use C++ and preferably boost libraries but currently this seems like I will not be able to do so.
Basically I am asking how do companies/professionals go about using Linux as a development environment? Is what I described above a common occurrence? Do you simply pick a version and a compiler and stick with it throughout the product lifetime to ensure that the development environment doesn't change too much or can you freely upgrade the kernel, compiler etc. as you go along? Is it common to be constrained by what a particular vendor can provide. Would anyone be prepared to give their opinion as to whether ubuntu 8.04 is a suitable choice of OS for development of industrial control software?
I am not a linux expert at all, but my research and experimentation so far is leading me to conclusion that I should abandon the linux approach and use DOS. Our company has no linux knowledge and is very small and for personal career reasons I have no interest in learning redundant technology like DOS.
I realise this is not exactly a yes/no type question but any responses will be gratefully received.
GCC 4.2 has no C++11 support but the C++03 support should be good and you should be able to find a version of Boost that can deal with that quite easily.
Ultimately, Linux has many upsides you won't find in DOS- for example, no segmentation, virtual memory, and such things that will make it easier and faster to develop software, not to mention additional libraries you might need, as absolutely nobody whatsoever will support DOS today.
With linux-based systems there's not much reason to stick with fixed OS+toolchain version, because backwards compatibility is a very serious issue in Unix-world. Sometimes it is good to target certain fixed system, but frankly these are rather rare, and even then the development can be done on up-to-date systems as long as testing is done on the target macine/platform.
Basically you could just upgrade to for example Ubuntu 12.04 LTS(long term support) for development and stick with it, it is very unlikely that there would be any sorts of uncompatibility problems on the target platform/machine.
Libraries and such tend to change between Linux distros, new versions of linux distros, and other *nix OSes.
I once worked on a C++ application that had to run on both Windows and RHEL. I was the 'Linux guy' on the team, so I got to deal with coaxing all the open-source linux libraries we were using to build and work on Windows (using cygwin), and getting the latest changes made by the devs working on Windows to work on Linux.
Midway through development, we upgraded to a newer version of RHEL. It was not a fun experience. Library versions had changed, some had been removed in favor of other 'equivalent' libs, etc. Shaking out all of the problems caused by changing gcc versions took a little while too (granted, the newer gcc version was a bit less forgiving and exposed some stuff in our code that probably wasn't quite right anyway).
A couple of days before a big demo, management informed us that the app needed to run on Solaris as well. That was not a trivial task -- Solaris is NOT Linux. They hinted about wanting it to run on IRIX at one point. Glad that didn't happen.
I would recommend that you pick a specific version of a Linux distro, gcc, etc. and stick with it throughout development. Upgrading that stuff can happen later, when the software is in maintenance. RHEL offers long-term support, at a cost. You might also consider the newly released Ubuntu 12.04 LTS
Related
If I want my software to run on Red Hat Linux 6.0, do I have to build it on 6.0? Or can I build it on 6.3? (Similar question for 5.X) I'm asking a general question about runtime implications of shared libraries and similar "automatic" dependencies that get sucked in during the build process. And I'm interested only in the divergence between minor releases. I know that more things change between major releases. I'm interesting specifically in RH and RH-derived distributions. My program is written in C and C++. I think the biggest dependency I need to worry about is the GCC runtime libraries for C and C++. Is there a web page I can use to verify which GCC updates were used in which RH minor releases?
To be clear: I understand the goal and commitment to compatibility between update releases going forward. Upgrading from 6.1 to 6.2 should not break my existing applications. In order to build on a newer update and run on an older update, I would need the reverse kind of compatibility. I need 6.1 to be compatible with things built on 6.2. In general this kind of compatibility is impossible to achieve on a wide-spread basis, across all config files, libraries etc. But I only need a narrow slice of reverse compatibility.
I have an app that was designed, written and built successfully on 6.1. Now I want to build it on 6.2, but I want it to still run correctly on 6.1. Is there a general software release practice on Linux that you always have to build on the oldest update release that you want to support? Or do most people use trial-and-error to determine whether their app runs on older update releases? If you use trial-and-error, how much "error" shows up in the equation?
I am required to write a C++ application to run on an embedded Linux setup (DMP Vortex86DX processor). The vendor provides a minimal linux installation image that can be installed to the board and contains appropriate hardware drivers. My question is motivated by the answer to my previous question about writing Linux software on a particular kernel to run on a different kernel . I don't really know where to start when it comes to writing the software with regards to ensuring compatibility.
My instinctive approach would be to install the same versions of g++ on the embedded device and on my desktop development machine, write the application on the dev maching, copy to the board and compile it there. This seems madness though and I find it hard to believe that this is how embedded software is developed. With regards to the answer to my previous question, is there a way I can simply build on my desktop but use the version of glibc that exists on the embedded device - if so how can enforce linkage to a specific version? Or is it possible to build everything statically so that the application doesn't link to anything dynamically (I doubt this is possible).
I am a total novice to embedded development, and foresee months of frustration unless I can get hold of some good advice or resources. Any pointers or suggestion of where to start will be very gratefully received no matter how simple or trivial they seem - I really am starting at the very bottom with regards to embedded stuff.
OK, given the fact that the Vortex86SX/DX/MX claims to be x86 compatible, a small set of compiler switches should enable you to compile code for your target machine: -m32 to ensure 32bit code, and no -march switch targeting a specific CPU.
Then you'll need to link your code. As long as you don't use anything fancy, but simple established glibc functions, I'd expect the ABI to be the same on your development machine and the embedded system. In other words, you compile against your host libraries, copy the binary to the embedded system, and it should simply run using the libraries available there.
If X-Linux were to use some other libc, like uclibc or similar, then you'd need a cross compiler on your host. I have little experience with Ubuntu in that regard, but I know that the sys-devel/crossdev package for Gentoo linux makes generation of cross-compilers very easy. This can be both for different architectures (not needed in your case) and different libraries (like e.g. uclibc).
I'd say simply give copying the binaries a try, and report back if you encounter any problems there.
I am a primary windows developer with experience in C#, .NET, Visual C/C++. I want to lean C/C++ development in linux in order to create portable GUI applications which run on both Windows and Linux.
I have used Fedora in past (2005). Want your suggestions to know which is the best distribution currently to learn programming in linux.
You can't really go wrong with any of the major ones. Personally I use Debian, but Fedora and OpenSUSE are good choices as well.
I would also like to point out that you can use C# to create portable GUI applications. Have a look at Mono and Gtk#. I have developed quite a few Gtk# apps and they usually run flawlessly on Windows and Linux, with very little work on my part. It might not be a bad introduction to coding on Linux, as you will be able to use a familiar language.
Any modern Linux distribution will do, as they all includes (or makes it easy to install) GCC. To easily create portable GUI applications, I would recommend taking a look at Qt.
Since every distro worth its salt has a Development Package that includes gcc, g++ and gdb, it's really going to come down to the IDE you develop your code in. Eclipse is an excellent IDE for C & C++ which just happens to be written in java. So long story short, use whatever distro you are comfortable with, it really doesn't matter all that much.
There is none Distribution you couldn't use. If you want an easy distribution working almost out of the box. With a lot of things configured automatically i would suggest you use ubuntu.
If you like to do more things on your own I'd tend to debian. Anyway you could simply code with qt and use the linux box for debugging only.
Slackware, ArchLinux or CentOS.
Stay away from Ubuntu and its derivatives, you will spend more time messing with packet manager apt-get than doing code. If you choose Debian-derivatives you will spend time wondering why your programs dont work only to find out you need packetname-devel also (!)
A base Slackware install should be enough to get you started, if you would like to keep having the latest programs, use ArchLinux.
You wrote "to create portable GUI applications which run on both Windows and Linux" - I suggest that you consider Qt (used to be from Trolltech now part of Nokia). http://qt.nokia.com/products/
I'm taking an Introduction to C++ this semester, so I need to set up development environments in both my Windows and Ubuntu partitions (I switch between them). I was planning to use GCC in both environments for consistency and because I plan to do my serious C++ developing in Linux with GCC.
It appears that installing MSYS and MinGW is the best way to use GCC and replicate my Linux dev environment. However, just setting up MSYS and MinGW in Windows appears to be a long and arduous process, and I'm imagining that I will have limitations or compatibility problems in the future.
Do the benefits of setting up a MSYS Linux-like development environment on Windows outweigh the costs?
Will I be able to use all the libraries that I could if I were using Visual C++?
I think you're going about this the wrong way - I would actually suggest you use Visual Studio on the Windows environment, rather than going out of your way to setup GCC. It's a benefit, not a drawback, to run your code on multiple compilers from multiple vendors.
Both GCC and Visual Studio are highly conformant (at least recent versions). You won't have any trouble with standard libraries and going between them, and if you do have trouble, it's probably an issue in your code.
I've always installed cygwin on Windows. To me, Windows is completely unusable without it. I've never really run into problems with DLLs mentioned above. However, I've also rarely used the GCC compiler, so I don't know how it compares to Visual Studio for general programming. For anything with a Windows GUI or Dot Net based, I would definitely stick with Visual Studio.
If you stick with the automated installer, MinGW installation is not painful at all. Unfortunately, that currently gives you GCC 3.4.5, rather than the newer 4.4.0 release that they also provide sans installer.
In reality, for course work, 3.4.5 will be just fine, I imagine.
Use gcc on Ubuntu and Visual Studio on Windows to get exposure to both. This is an intro course so Windows, Linux, Visual Studio, gcc are just the tools you need to master C++ and data structures. Mastering the tools will come over time and they will change.
I personally develop for windows using a pure Linux environment using mingw-gcc on Linux to cross-compile for windows.
I put a tutorial on how to set it up for OpenSSL/Qt4 # http://www.limitlessfx.com
Do you do this to get .exes or just to be able to work on both OSes?
If you feel more comfortable with GCC than VC, setting up Mingw/Cygwin is possible but doesn't give you any new functionality (beside .exes). Instead, I suggest you turn one of your partitions into a virtual machine - this way you can have both OSes open at once! (My personal choice is Windows inside Linux, YMMV.)
The benefit of developing on Linux is ready availability of tons of development tools and libraries. Also, big builds are noticably faster.
Since you said "I plan to do my serious C++ developing in Linux with GCC", VC++ may not be what you really want. Many libraries just don't compile well in VC++. Try some yourself. Instead, consider running Linux on Windows. There are several ways to do this:
Use PuTTY to connect to a Linux machine, and use Xming to see the UI windows. I would only do this over a LAN.
Consider coLinux. You can run Linux under Windows and just shut-off Linux when you are done.
Consider other virtualization options like VMWare to run Linux. Pretty much the same as coLinux, but it might be easier to setup.
You may even want to install Linux directly on your machine. You can always use tools like Wine or VMWare to run Windows if you need it.
I would like to port my C/C++ apps to OS X.
I don't have a Mac, but I have Linux and Windows. Is there any tool for this?
For Linux, there is a prebuilt GCC cross-compiler (from publicly available Apple's modified GCC sources).
https://launchpad.net/~flosoft/+archive/cross-apple
Update for 2015
After so many years, the industry-standard IDE now supports OSX/iOS/Android.
http://channel9.msdn.com/Events/Visual-Studio/Connect-event-2014/311
Embarcadero's RadStudio also supports building OSX/iOS/Android apps on Windows.
This answer by Thomas also provides a cross-compilation tool.
For all these options you still need a real mac/i-device to test the application.
I have created a project called OSXCross which aims to target OS X (10.4-10.9) from Linux.
It currently supports clang 3.2 up to 3.8 (trunk) (you can use your dist's clang).
In addition you can build an up-to-date vanilla GCC as well (4.6+).
LTO works as well, for both, clang and GCC.
Currently using cctools-870 with ld64-242.
https://github.com/tpoechtrager/osxcross
There appears to be some scripts that have been written to help get you set up cross compiling for the Mac; I can't say how good they are, or how applicable to your project. In the documentation, they refer to these instructions for cross-compiling for 10.4, and these ones for cross compiling for 10.5; those instructions may be more helpful than the script, depending on how well the script fits your needs.
If your program is free or open source software, then you may wish instead to create a MacPorts portfile (documentation here), and allow your users to build your program using MacPorts; that is generally the preferred way to install portable free or open source software on Mac OS X. MacPorts has been known to run on Linux in the past, so it may be possible to develop and test your Portfile on Linux (though it will obviously need to be tested on a Mac).
Get "VMware Player"
Get "Mac OS X vm image"
Compile/Debug/Integrate-and-test your code on the new OS to make sure everything works
When you are trying to get something working on multiple platforms you absolutely must compile/run/integrate/test on the intended platform. You can not just compile/run on one platform and then say "oh it should work the same on the other platform".
Even with the a really good cross-platform language like Java you will run into problems where it won't work exactly the same on the other platform.
The only way I have found that respects my time/productivity/ability-to-rapidly iterate on multiple platforms is to use a VM of the other platforms.
There are other solutions like dual-boot and ones that I haven't mentioned but I find that they don't respect my productivity/time.
Take dual-booting as an example:
I make a change on OS 1
reboot into OS 2
forget something on OS 1
reboot into OS 1
make a change on OS 1
reboot into OS 2 ... AGAIN...
BAM there goes 30 minutes of my time and I haven't done anything productive.
You would need a toolchain to cross compile for mach-o, but even if you had that, you won't have the Apple libraries around to develop with. I'm not sure how you would be able to port without them, unfortunately.
Apple development is a strange beast unto itself. OS X uses a port of GCC with some modifications to make it 'appley'. In theory, it's possible to the the sources to the Apple GCC and toolchain as well as the Apple kernel and library headers and build a cross compiler on your Windows machine.
Why you'd want to go down this path is beyond me. You can have a cheap Mac mini from $600. The time you invest getting a cross compiler working right (particularly with a Windows host for Unix tools) will probably cost more than the $600 anyway.
If you're really keen to make your app cross platform look into Qt, wxWidgets or FLTK. All provide cross-platform support with minimal changes to the base code. At least that way all you need to do is find a Mac to compile your app on, and that's not too hard to do if you have some technically minded friends who don't mind giving you SSH access to their Mac.
You will definitely need OS X somehow. Even if you don't own a Mac, you can still try some alternatives.
I found this small documentation on the net:
http://devs.openttd.org/~truebrain/compile-farm/apple-darwin9.txt
This describes exactly what you want. I am interested in it myself, haven't tested it yet though (found it 10 minutes ago). The documentation seems good, though.
You can hire a mac in the cloud from this website. You can hire them from $1, which should be enough (unless you need root access, then you are looking at $49+).
There are a few cross-compiler setups, but nearly all of them are meant for distcc-style distributed compiling. To my knowledge there is no way to directly target the Mac platform without actually having a Mac. The closest you can get without resorting to QT or wxWidgets is OpenStep with GNUStep or similar, but that's not a true Cocoa platform, just very close.
I know this question isn’t very active but answering anyways. Why don’t you try using TransMac, then download the XCode image and do it that way? Or you can use a VM, or Sosumi. You’ll find a video on youtube about sosumi, definitely.
The short answer is kind of. You will need to use a cross-platform library like QT. There are IDE's like QT Creator that will let you develop on one OS and generate Makefiles for others. For more information on cross platform development, check out the cross-platform episodes of this podcast (note that the series isn't over and new episodes appear to come out weekly).
As other answers explain you can probably compile for a Mac on Windows or Linux but you won't be able to test your applications so you should probably spend the $600 for a Mac if you’re doing professional programming, or if you’re working on open-source software find a developer with a Mac who will help you.