Getting started C++ on Linux books

[kcp11]

I am an experienced Windows C++ programmer but have no experience with Linux. I am starting to look at moving part of a commercial C++ Windows program to Linux. The Linux program will strictly be a command line program to do large scale number crunching on Linux.

What would be a good book (or books) to read in preparation for this? I am starting from absolute zero, for example what C++ compiler to use. Compiler options. What is the Linux debugger? I plan to rent an account on a Linux server rather than set up a Linux desktop or laptop. Is there a command line debugger, or a remote login facility to use a graphical debugger off a server?

Also, I am expecting to get into the more advanced topics of shared memory between processes, threads, and shared objects (which I understand is the equivalent of Windows DLLs on Linux).

I am thinking it might help me get started to read a good book. Or if there are tutorial enough web resources that will start from the beginning. But I prefer to purchase a good book or two if that would provide better getting started background.

Can someone recommend a book or books?

[gerard4143]

For starters try "Beginning Linux Programming"...Gerard4143

[GNU-Fan]

For reference:
The GNU C Library - GNU Project - Free Software Foundation (FSF)

[Rubberman]

One question is, how much is your code dependent upon Microsoft's C++ libraries and frameworks (other than STL, etc)? My experience in cross-platform (Unix/Linux/Windows) C++ development (15+ years) has been that it is a LOT easier to migrate applications from Linux/Unix to Windows than vice-versa. At least this is a command-line program, so you don't have the intricacies of a GUI API to deal with. That's a big plus.

I don't know of any books for migrating Windows C++ to Linux. The main compiler for Linux is the GNU compiler suite, along with gdb for the debugger. It is a command-line debugger, though there are tools that give you a gui interface to it, such as the Eclipse toolset. If you are using a remote account and want to run GUI tools like Eclipse, then you can install an X-server on your local computer and the remote GUI applications will happily display on your Windows desktop. The cygwin operating environment (a Linux-like environment for Windows) has a good X-server, plus all the normal Linux tools such as ssh for secure access to your remote development system.

Linux has very good shared memory support, though I don't think it handles memory-mapped files as well as Windows does. It supports the POSIX pthreads libraries, and shared library support is in general (IMO) better than Windows' DLLs.

You might want to check out The Linux Documentation Project for a wide variety of Linux documentation online.

[kcp11]

One question is, how much is your code dependent upon Microsoft's C++ libraries and frameworks (other than STL, etc)? My experience in cross-platform (Unix/Linux/Windows) C++ development (15+ years) has been that it is a LOT easier to migrate applications from Linux/Unix to Windows than vice-versa. At least this is a command-line program, so you don't have the intricacies of a GUI API to deal with. That's a big plus.... (snip)

I believe that the number crunching command line program has no dependencies on Microsoft C++ libraries. That is intentional, that I wanted it from the start to not be Windows dependent. The point of the design was to keep the non-visual number crunching core very generic C++ so that it could be portable to any operating system with a C++ compiler. All dependencies are isolated in a limited number of functions, and that is mostly only the Windows DLL linkages. Although I will really find out how successful this was when I actually try to compile on Linux.

On the other hand, as you say the user interface is very Windows dependent, which is why (at least initially) the goal is to move only command line number crunching to Linux.

Actually I have UNIX experience from a long time ago, but I have never touched a Linux computer. Your post helps to in a few paragraphs catch me up. Thanks, this helps. It is good to know that there is a command line debugger. That should be enough for my initial project.

Actually I am already using cygwin, but currently only for bash and simple utilities like diff, since I am familiar with these tools from my UNIX days. I didn't know that cygwin supports an X-Server.

Also I have just discovered Wine. I am now wondering if I could run the Windows GUI with Wine and the number crunching with the native Linux command line program. That would yield a complete Linux version very easily. The Windows user interface is not performance critical. It is only the number crunching that is performance critical, which is why I want a native Linux version.

Something I am not clear about is to what extent binary programs are compatible between Linux distributions (and for that matter, FreeBSD). Will a binary compiled on Red Hat run on Ubuntu, or on FreeBSD? Do I need to be concerned about supporting multiple Linux distributions, or can I develop the software on one distribution and be confident it will run on all Linux distributions?

Also, the software includes an end user programming environment that is distributed as .objs in .libs. End users compile with the C++ compiler, linking in the .libs to create the command line program. So I suppose that is a question of .obj and .lib compatibility between Linux distributions. I would think that might depend on using the same GNU compiler on the various distributions. Can I have a single set of .libs that will work on all Linux distributions with the default C++ compiler?

[Rubberman]

I believe that the number crunching command line program has no dependencies on Microsoft C++ libraries. That is intentional, that I wanted it from the start to not be Windows dependent. The point of the design was to keep the non-visual number crunching core very generic C++ so that it could be portable to any operating system with a C++ compiler. All dependencies are isolated in a limited number of functions, and that is mostly only the Windows DLL linkages. Although I will really find out how successful this was when I actually try to compile on Linux.

That is a good design policy.

Also I have just discovered Wine. I am now wondering if I could run the Windows GUI with Wine and the number crunching with the native Linux command line program. That would yield a complete Linux version very easily. The Windows user interface is not performance critical. It is only the number crunching that is performance critical, which is why I want a native Linux version.

It may be possible, but I'm not sure without trying it with at least a simple test case - can a Windows application running with Wine execute a Linux application (even a simple shell script)?

Something I am not clear about is to what extent binary programs are compatible between Linux distributions (and for that matter, FreeBSD). Will a binary compiled on Red Hat run on Ubuntu, or on FreeBSD? Do I need to be concerned about supporting multiple Linux distributions, or can I develop the software on one distribution and be confident it will run on all Linux distributions?

The short answer to that is, it depends. Statically linked applications are less likely to have linkage problems with different versions of shared libraries, unless you are providing the libraries. Generally this isn't too much of a problem, and the compatibility issues are normally determined by the package manager when you install the application, provided you take the package approach. That, as they say, is another kettle of fish.

Also, the software includes an end user programming environment that is distributed as .objs in .libs. End users compile with the C++ compiler, linking in the .libs to create the command line program. So I suppose that is a question of .obj and .lib compatibility between Linux distributions. I would think that might depend on using the same GNU compiler on the various distributions. Can I have a single set of .libs that will work on all Linux distributions with the default C++ compiler?

In Linux/Unix-land, .libs are static libraries such as libname.a vs libname.lib on Windows. Shared libraries are libname.so vs libname.dll. Object files are filename.o vs filename.obj. The approach you are telling me about is not a bad one for multi-linux system support, at least for systems that share a CPU family, such as the Intel x86 family. However, bear in mind that there are 32-bit and 64-bit versions of Linux for the Intel family. Fortunately, a 32-bit program will run in a 64-bit OS. In any case, you want to keep this in mind.

That said, the answer is yes, you can supply static or shared versions of your library that the recipient can link with your object files and system libraries to make an executable suitable for their environment. You might want to ship shared libraries, however, as that gives you some flexibility with support. Suppose you find a small but serious bug in one of your libraries, that doesn't change any fundtion/class signatures (linkage-compatible). Using shared libraries you will be able to ship them the library only which they can simply use to replace the one installed on their system. The next time they run the application, the new version will be utilized. One nice thing about Linux, is that you can replace a file that is currently open and in use by some application, and they will not even be aware of it until they close and reopen it. On Windows, an open (even for read access) will lock the file so it cannot be moved, updated, or accessed for the most part.

[kcp11]

Good to hear that you think that distributing .libs will work on multiple distributions. In Windows I distribute static libraries, and I expect I will continue that in Linux. The whole software isn't that large, and it is easy enough to send and install a complete update. So there isn't much need for replacing a shared library. Rather, update the whole software has been working fine.

Thank you also to the others who responded. I have a copy of "Beginning Linux Programming" on order. Also the references to both The GNU C Library and The Linux Documentation Project look very useful. From my first 24 hours into Linux, there seems to be a wealth of good documentation.

I feel like I am on my way

Another resource I ran across is that the book Advanced Linux Programming is available as a free PDF download (google is your friend, the forum won't let me post a URL since until I have made 15 posts), This is another major well reviewed book. I found mention of this when looking around amazon.com for the "Beginning Linux Programming". But myself I was looking for a paper book that I can carry around, so I think I will start with "Beginning Linux Programming" first.

[Rubberman]

There are a number of really good Linux programming books with PDF's available online. O'Reilly publishes a bunch of them. Very useful to keep around for quick reference. My 7'x10' technical bookshelf is full now, so I need for newer books to be eBooks in order to keep it from collapsing!