I was thinking alloca...

I've been looking for a tester that doesn't involve using a third party web site. Thanks!

I'm starting to appreciate the equivalence of DLL-Hell on Linux.

But, in some ways, Linux magnifies the problem.

It's so strongly encouraged that you use shared libraries that it seems like you have to practically pull teeth to use static libraries. People generally say, "It is encouraged to use shared libraries," and make up all kinds of smarmy comments (at least, the ones who don't seem to grasp that some people have special needs requiring that you not compile everything on each machine).

Of course, I'm sure it's my fault for wanting to use a modern compiler when it seems this environment has machines that are... obscolete. But, sheesh...

Did I miss something - you now work at a Linux shop?
Well, you got what you wanted I guess.

But... don't upgrade the compiler. Use the distro-supplied... or upgrade the distro.

Heh... I work where we have both Linux and Windows.

We're going into the next phase of our software efforts, which involves writing more sophisticated code (rather than something for a demo). That code requires some code in common between Windows and Linux.

So, I saw an opportunity to write the service/daemon code that compiles for Windows SCM or for a Linux daemon depending on which machine does the compiling.
It seems to work reasonably well, and that allows me to write one bit of code in C++ that works in both Linux and Windows.

Except for the bit where the shared libraries on some of these machines are horribly out of date... so I should probably compile for static libs, like I do for Windows.

depends which libraries you're talking about.

Boost, and the standard c++/c libs.

Although, the more I read on this topic, the more I wonder if I couldn't just install the missing libraries when I install the executable itself somehow.

c++ is debateable, but I can't imagine why you would want to link libc statically. this is not standard practice, nor necessary practice, nor can I imagine why it would be merely expedient.

you'll probably just cause yourself more trouble, that way.

if you have a mix of old/new distributions on live servers, your toolchain needs to be based on the oldest binaries in your server farm.


or you need to think about source installs.

So you're basically suggesting to me that Linux discourages advances if you wish to write software professionally for that platform.

Unless you are in the luxurious position of telling everyone that they have to move to the version of Linux to which you compile your sources.

I want to like Linux, but this is really, really bad.

No... I'm suggesting that you don't know Linux well enough to do what you seem to be proposing.

To pick a hypothetical example, Ubuntu 10.04 is based on kernel 2.6. 12.04 is based on kernel 3.0.

The C library from 12.04 might depend on kernel 3.0 features in some areas. It might depend on other components of the 12.04 distribution that are not present on 2.6. Depending on what specific system calls you use, of course. There are probably ways you could avoid those dependencies, but it's really going to save you more time in the end to dynamically link with the C library from 10.04. Because forward compatibility is guaranteed, but backwards compatibility is not necessarily guaranteed. That way you know your'e taking advantage of interfaces that were available on 10.04.

libstdc++ is a different story. If you are unwilling to code conservatively enough to limit yourself to C++ features that were available on the older distribution's compiler (10.04 in this example) then it might be possible to *compile* a newer version of g++ on 10.04, and link statically with the libstdc++ from that version. The resulting binary should carry forward to 12.04. But building on 12.04 and expecting stuff to carry backwards is not the supported path and does not work in general unless you are very careful. ***This is the same situation as windows -- why would you expect to be able to take GDI.DLL from Vista and drop it onto XP?***


And really, you should be dynamically linking where you can, so that it's possible to pull in security updates operationally without recompiling all the time.


tl;dr: don't link statically with libc. But you can consider it for other libraries.

Okay, yeah, now that I think of it, I'm being a bit unfair to expect forwards compatibility to a certain extreme.

But so far, in the past, when I've written stuff that doesn't use a particularly obscure API call on Windows, I could make the same thing work on extremely old versions of Windows without having to concern myself about the age of the compiler itself... with only one exception. VC++ 2013 requires you specify a different toolset if you want your software to work on XP or older. I mean, after all, they provide a separate library for the C/C++ runtime, and that library doesn't require anything terribly new out of the kernel (well, until VC++ 2013, and even then, I suspect if I dig enough, I'll find it is security-related or somesuch).

For what I'm doing, I am not requiring anything amazingly new out of the kernal on either Linux or Windows. A network stack, threading, file i/o... none of those things are revolutionary these days. Yet, for some reason, newer compilers are making older operating systems obscolete?

That just seems very, very weird.

Yeah, I can revert to using older compiler features and avoid the Kool Stuff, but I confess, it sucks.

On Linux, the C library fills a larger role than it does on Windows. Windows, all the fundamental OS interfaces are in KERNEL, USER and GDI with some semblance of symbol versioning. The C library on Windows is just viewed as this little shim that's specific to C programs. On Linux its more fundamental to the operating system.

I'm going to make the assumption that the Kool Stuff you prefer/require is all C++ language features and C++ library features. That's separated from the C library to a degree, on Linux.

**This is not always supported**, but a quick hack you might try, is to compile with libstdc++ statically linked, and libc dynamically linked. Even if you're compiling on a newer distro, this *might* result in something that will run on an older distro. Symbol versioning in libc can sometimes salvage this, if your binary happens to avoid symbol versions that are not present in the older libc.

But to be really safe I would try to properly install a newer version of gcc-c++ on the oldest distro you need to support, and use that host as your build host. Assuming you're avoiding some of the poorly-versioned libraries out there, this may work. You may end up with some weird bits that have to be installed along with your binary... libstdc++ ships with the compiler, rather than libc, and preferably you want to get a libstdc++ that is compiled and linked against the oldest libc you need to support.


That is, if you're not willing to just remove the Kool Stuff, which might be the most conservative thing for you to do...

The source install of gcc-c++ often supports somewhat older base OS versions than what you can obtain just by installing the gcc-c++ binaries that come with newer distributions (which are, by definition, compiled and linked against that same newer distro.)

Both MS and Apple DO do a better job of some of this stuff, admittedly. Microsoft basically provides a set of alternate headers and link stubs for their older OSs so that you can cross-compile against the older stuff.

the kernal on either Linux or Windows. A network stack, threading,
file i/o... none of those things are revolutionary these days. Yet,

Those things aren't the problems. It's the constant evolutions of C++ that present the biggest challenges. I remember hacking around with stuff like TOra, how newer compilers would break older C++ code between consecutive major releases of distributions... not fun.

Yeah, I've had my fair share of newer C++ compilers breaking stuff in the Windows world as well.

Although, as I dug deeper and learned more about C++, I came to learn that a lot of the code that broke was not exactly written properly to start. Although, admittedly, some of the code was written in a particular way because the compiler itself wasn't quite right... but that's probably a discussion for another forum, heh.

I do pretty well now, writing C++ that handles upgrades in the compiler with quite a bit of grace. So, that's less of a problem for me.

I wanted to use some of the newer features available in the latest versions of C++, in part, to keep up with some of those things, and in part, because the language is getting interesting. Lambda functions, certain move semantics that help optimize 'copy' operations while keeping your code safe, variadic parameters that are type-safe... the language has really come a long way in the last few years.

But, yeah, I know how to use the old stuff, and I can certain continue to write that way if I have to.

Okay, I'll look around for 'backport' and see what that involves.

We have a need for that for some other stuff, for which we have no sources, but we need these things to work on older Linux machines. If 'backport' can help with that, it'll be a bonus!

http://backports.debian.org/