C++ .a: what affects portability across distros?

Question

I'm building a .a from C++ code. It only depends on the standard library (libc++/libstdc++). From general reading, it seems that portability of binaries depends on

• compiler version (because it can affect the ABI). For gcc, the ABI is linked to the major version number.
• libc++/libstdc++ versions (because they could pass a vector<T> into the .a and its representation could change).

I.e. someone using the .a needs to use the same (major version of) the compiler + same standard library.

As far as I can see, if compiler and standard library match, a .a should work across multiple distros. Is this right? Or is there gubbins relating to system calls, etc., meaning a .a for Ubuntu should be built on Ubuntu, .a for CentOS should be built on CentOS, and so on?

Edit: see If clang++ and g++ are ABI incompatible, what is used for shared libraries in binary? (though it doens't answer this q.)

Edit 2: I am not accessing any OS features explicitly (e.g. via system calls). My only interaction with the system is to open files and read from them.

Answer 1

It only depends on the standard library

It could also depend implicitly upon other things (think of resources like fonts, configuration files under /etc/, header files under /usr/include/, availability of /proc/, of /sys/, external programs run by system(3) or execvp(3), specific file systems or devices, particular ioctl-s, available or required plugins, etc...)

These are kind of details which might make the porting difficult. For example look into nsswitch.conf(5).

The evil is in the details.

^{(in other words, without a lot more details, your question don't have much sense)}

Linux is perceived as a free software ecosystem. The usual way of porting something is to recompile it on -or at least for- the target Linux distribution. When you do that several times (for different and many Linux distros), you'll understand what details are significant in your particular software (and distributions).

Most of the time, recompiling and porting a library on a different distribution is really easy. Sometimes, it might be hard.

For shared libraries, reading Program Library HowTo, C++ dlopen miniHowTo, elf(5), your ABI specification (see here for some incomplete list), Drepper's How To Write Shared Libraries could be useful.

My recommendation is to prepare binary packages for various common Linux distributions. For example, a .deb for Debian & Ubuntu (some particular versions of them).

Of course a .deb for Debian might not work on Ubuntu (sometimes it does).

Look also into things like autoconf (or cmake). You may want at least to have some externally provided #define-d preprocessor strings (often passed by -D to gcc or g++) which would vary from one distribution to the next (e.g. on some distributions, you print by popen-ing lp, on others, by popen-ing lpr, on others by interacting with some CUPS server etc...). Details matter.

My only interaction with the system is to open files

But even these vary a lot from one distribution to another one.

It is probable that you won't be able to provide a single -and the same one- lib*.a for several distributions.

^{NB: you probably need to budget more work than what you believe.}