merge with github repo

Signed-off-by: Julius Plenz <julius@plenz.com>

(See issue #14.)

* makefile-improvement:
  Adjust README for Makefile update.
  GNU Make best practice

(Closes issue #14.)

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

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

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

(This fixes issue #3.)

(See Issue #12.)

This reverts commit 0a214bdb.

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.)

* 'master' of git://github.com/onlyjob/nocache:
  minor man pages corrections (lintianisation): "hyphen-used-as-minus-sign"

* '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

added BASEDIR to nocache.global (modifiable by sed)
simplified LD_PRELOAD declaration

(Otherwise `prove` would complain about “out of sequence” tests.)

* n-times-fadvise:
  Update man pages to reflect "-n" option
  Only do multi-fadvise if previous call was successful
  Add explanation of -n flag / NOCACHE_NR_FADVISE env variable
  Implement "-n <n>" flag for repeated posix_fadvise()

There was a trivial-to-solve merge conflict in nocache.c

Reported-by: Reda Noushi <reda@logzilla.pro>

> one remark: what should nocache do if a non-zero value is returned by posix_fadvise()?
> 1. is it okay to continue executing it and returning the last value?
> 2. or stop execution and return the last non-zero value of fadv()?

* noushi/behavior_mods:
  nocache retrieves max fds from actual process limits.

* 'master' of git://github.com/paulharris/nocache:
  Adjusted script so it will preload the .so from the script's directory

Thanks again, kocmo, for noticing.

Thanks to kocmo for the patch.

man pages