5686877cd4
Oh that poor ol' build system. With this patch it will have gone through three separate incarnations in terms of NUMA/Node support. Those 3 iterations consisted of: 1. A 'porridge too hot' where the top numa support was enabled if it was built in the presence of libnuma and the numa.h header. But if the numa library wasn't part of core packages, that would have broken poor old top. 2. A 'porridge too cold' where numa support was off by default and must have been explicitly enabled when the ./configure script was run. This could have meant that distros might not distribute a numa-aware procps, even though their numa library would have been distributed. 3. And this 'porridge' where the top numa support will become a 'plug-in' feature activated when the presence of libnuma.so can be verified at runtime. We'll do our own loading and symbol resolution (with some help from dlopen in libdl). Thus maintainers' responsibility for enabling numa support and then satisfying that library dependency is now an entirely optional --disable-numa. As Goldilocks might say about our current configure.ac "Ummm, I think this porridge tastes just about right". Reference(s): . 1) too-hot commit87ac6383bb. 2) too-cold commit53fd7dd1ed. original idea from: Dr. Fink <werner@suse.de> http://www.freelists.org/post/procps/top-NUMA-node-CPU-utilization-support,18 Signed-off-by: Jim Warner <james.warner@comcast.net>
COMPATIBILITY
This code is intended for use with Linux 2.6.xx, 3.x and
hopefully all future kernels.
INSTALLATION
If you are using git version of the project you need extra step.
./autogen.sh
After that, and everyone using .tar.xz version of procps-ng, can
do normal build. Read './configure --help' to select options for
your needs.
./configure
make
make install
If you have DejaGNU installed you can run optional test suite.
make check
HOW TO CONTRIBUTE
See Documentation/BUGS file.
PACKAGING
If you are a downstream maintainer (packager) for a Linux
distribution, please avoid causing troubles. This section
applies to you.
Avoid maintaining distribution specific patches. Send your
patches to upstream, where they are at least reviewed, if not
included.
Please forward bug reports. If your bug database is public and
busy enough to bother with, please make this known. Follow
Debian's lead in making the bug database easy to comment on via
email without need for an account.
For normal packages, ensure that you do not add debugging flags
to the CFLAGS variable.
UPSTREAM & BUG REPORTS
procps-ng <procps@freelists.org>