(if it isn't completely clear, doing things as described above will link zlib with the compiler toolchain you're building, but not with binaries generated by that toolchain - by default.)

That'd work.

If I did that, of course, I'd have to ensure that I install the library somewhere on the OS. It's yet another dependency I would need to track.

If I do it my way, I don't have that dependency, and setup is simplified.

Perhaps I should point out that the two functions I needed out of the updated zlib was 1. compressBound, which simply calculates an estimate of how much space is needed for the compression, and 2. ceil, which is used by compressBound for its calculation, is normally included in 'math', but for some peculiar reason I can't link that library into the compiler.

Neither of these functions are revolutionary or terribly difficult to implement.
If I needed 10 functions, some of which involved some relatively intricate programming that would be unwise of me to attempt, yeah, I would suffer the setup dependency. But for the price of creating two very simple functions, avoiding a setup dependency seems like the better way to go.

At least, that's my reasoning.

That looks rather useful... isolated dev environments in a flash.

Fucking hell... trying to read anything about Docker is like reading a web site full of nothing but buzzwords.

I feel like I'm listening to Weird Al's "Mission Statement" tune.

I assume eventually I'll read something that actually has some real meat to it, but honestly, I'm incredibly turned off by all this buzzword shit.

Gah... fucking marketing...

The usual enmity between engineering and marketing continues.

Another awful thing... Valhalla Linux doesn't have a concept of a steady clock within it.

The only clocks I can find for this is a clock that matches the 'real time', and is subject to the usual crap when you adjust the time, and process/thread CPU clocks, which are not exactly steady. There is no way that I can see right now that you can get a kind of clock that simply iterates over a steady rate of time, monotonically.

Did people writing for Valhalla wind up with obscure and weird problems when people changed their time?

(Sorry, I wrote 'Valhalla Linux', which is stupid... RedHat Valhalla is what I mean).

what you're looking for might be /proc/loadavg, which is used by the "uptime" command...

/proc/uptime ooks like the the same thing, higher resolution?

(I got this by running "strace" on the /usr/bin/uptime. the program queries both /proc/loadavg and /proc/uptime (oops) so the latter is the one that's relevant.

these have been around for a while, so they should work on rh6.2 even.

Thanks for the information!

Here's something else to add to it:

http://lwn.net/Articles/23313/

If I'm reading this correctly, back then, people tried to ensure that time marched forward by relying upon the NTP client to adjust the system clock in monotonic ways. So, you'd never change the system clock yourself... you would let NTP do it for you, and it would always adjust the clock in a fashion that is monotonic in nature.

Obviously, folks must have figured out how bad this idea was, as we now have CLOCK_MONOTONIC available for clocks in current kernels, but I guess we had some relatively naive notions about time back then.

Sooo, at least philosophically, I should be able to use the realtime clock as if it were the steady clock, and avoid adjusting the time/date on the machine, just as I guess they intended back in the day.

I have to figure out how to coerce my code to do this... it *really* wants CLOCK_MONOTONIC or the like. I tried #defining it to CLOCK_REALTIME and now I have a linking error. But I'm sure I can get past that with a little evil.

Heh... I worked around it by forcing the underlying boost::steady_clock class to use CLOCK_REALTIME instead of CLOCK_MONOTONIC (or variations). It isn't perfect, but it'll have to do since the OS doesn't have a proper monotonic clock.

If I felt plucky, I could maybe build one in some bizarre fashion using the boost::steady_clock interface but writing the underlying code that calls the usual OS APIs to do something with /proc/utime instead... if I can figure out how to make a timer that doesn't busy-wait within this context.

But I think for how I'm doing everything, this may be good enough. I'll know more when we get into testing.

Well, there is *One* *Simple* *Trick* that you can do to ensure monotonicity in userland ;) ;) ;)

(oh, and since this kind of stuff gets picked up by Google now, here's some additional details, in case someone else wants to do this).

If you find yourself in the ridiculous position of having to write code to work on a version of Linux using the 2.14 kernel, after figuring out how to build the GCC 4.83 compiler (not something I'll bother with here... just know that it's doable), you'll need the following in one of your .cpp files:

#if defined(__linux__)
#include <time.h>
#define CLOCK_MONOTONIC CLOCK_REALTIME
#pragma message "This OS doesn't support a steady clock. YMMV."
#include <boost/chrono/detail/inlined/chrono.hpp>
#endif

Oh, god, that is stupid.

There's another guard... #if !defined(CLOCK_MONOTONIC), that I missed.