added -n option to nocache.global
added BASEDIR to nocache.global (modifiable by sed)
simplified LD_PRELOAD declaration
Merge branch 'behavior_mods' of git://github.com/noushi/nocache

* 'behavior_mods' of git://github.com/noushi/nocache:
  added -n option to nocache.global added BASEDIR to nocache.global (modifiable by sed) simplified LD_PRELOAD declaration
Merge branch 'master' of git://github.com/onlyjob/nocache

* 'master' of git://github.com/onlyjob/nocache:
  minor man pages corrections (lintianisation): "hyphen-used-as-minus-sign"
Remove erroneous code duplication
support for kfreebsd and old FreeBSD systems.
Revert "support for kfreebsd and old FreeBSD systems."

This reverts commit 0a214bdbb24f18c62f44f97b3ee3cb9bce15daf6.

Apparently, building nocache on kfreebsd still fails, and anyway the linker
warns that posix_fadvise will always fail. So so wait until kfreebsd is
up-to-date with the POSIX standard. (See issue #12.)
Mention Debian pkg and kfreebsd warning in README

(See Issue #12.)
We don't want to mix 64 bit file opens with 32 bit file opens;

(This fixes issue #3.)
Space change
For visual consistency, don’t wrap dlsym calls
Supply “lazy initializers” in every intercepted function

The friendly folks at #musl say:

20:52 < dalias> i think it's good to have both that and the ctor
20:52 < Feh> This should increase robustness if it is in every function.
20:52 < dalias> because...
20:52 < dalias> several of these functions are required to be async-signal-safe
20:53 < dalias> so if the first call happened to be from a signal handler,
   you'd be in trouble if you didn't already have the ctor
20:54 < dalias> in theory another ctor in another lib or the app could run
   before yours and install and run a signal handler :-p but that's pretty
   unlikely and pathological
20:54 < dalias> so i think having both the ctor and the lazy-init keeps you
   safe in situations that will arise in the real world
Assert the existence of original functions

The friendly folks at #musl again:

21:17 < dalias> if you init the pointers both from the ctor and the "lazy
   init", then the assertion-failure/abort would happen during construction
   (either your ctor or somebody else's ctor calling your functions)
21:17 < dalias> so the program would exit "before it even gets started"
21:17 < dalias> and this is not so bad

21:18 < dalias> normally i consider it really bad practice for a library to
   abort the program
21:18 < dalias> but this happens during ctors, and there truely is no way to
   proceed
21:18 < dalias> if you've already replaced the program's library functions
   (open, etc.) with your copies, and then find that you can't actually supply
   working ones
Block all signals during store_pageinfo() and free_unclaimed_pages()

The friendly folks at #musl again:

21:34 < dalias> the cheap way around this problem is to block signals for the
   entire duration of the unsafe operation
21:35 < dalias> formally (by the rules of the standard) this is not sufficient
21:35 < dalias> because formally it's not just calling pthread_mutex_lock again
   on the same mutex  while the first call is interrupted that's undefined
21:36 < dalias> it's calling ANY unsafe function while ANY unsafe function (the
   same or otherwise) with any argument (e.g. not necessarily the same mutex)
   that gives undefined behavior
21:38 < dalias> but real-world-implementations don't have this maximum
   theoretical degree of unsafety
21:38 < dalias> so the approach i described (just ensuring your functions don't
   interrupt themselves or each other) should be enough to make them safe
GNU Make best practice