The existing build system would only require wide ncurses for
a wide watch and even if the library was there would not link
anything else to it.
The first issue which #123 made me think of, is if ncursesw
was there and ncurses is not, why not use ncursesw?
A more major issue is if programs such as slabtop are linked
to ncurses, then certain languages will display their text
wrong, as found in #237.
The days of assuming ASCII only is ok are over the build system
now does the following:
1. If ncursesw is available use this for all relevant programs
2. If ncursesw is not but ncurses is, use this instead
3. If you enable 8bit watch and either disable ncurses or
we cannot find ncursesw error at configure time.
In related news, I hate M4sh.
References:
procps-ng/procps#123procps-ng/procps#237
Signed-off-by: Craig Small <csmall@dropbear.xyz>
While the previous commit checked for a GNU environment so Hurd
compilied ok, this tripped up Cygwin. configure now explicitly tests
for the structure field rather than trying to guess through compilier
flags about what the environment tells us about signals.h
References:
commit d39d9db079
Signed-off-by: Craig Small <csmall@dropbear.xyz>
in include/c.h we check if HAVE___PROGNAME is defined, but the
corresponding macro for setting (or not setting) it is missing from
the configure script. This commit adds the missing macro, by
copying it from the macro in tmux.
With 4e7f4237 and 5e73c832, systemd library detection through pkg-config
was changed to unconditionally look for unified libsystemd.
This adds a fallback to match the previous behavior and find the split
libs as well.
References:
procps-ng/procps!128
Signed-off-by: Craig Small <csmall@dropbear.xyz>
What to call the new library?
Keep using libprocps wouldn't do, its a very different library from
the programs' point of view. It would also mean we could have some
clashes around the packages (two package names, same library name).
The ancient procps used libproc or libproc-a.b.c where a.b.c was the
package version. Kept the revision numbers down (it was always 0.0.0)
but the name of the library changed.
So if we use libproc-2 is there a clash with an ancient procps?
procps v 2.0.0 was around in 1999 so it was 22 years ago, also the
name of the library would have been libproc-2.0.0.so not libproc-2.so
so we're fine with that.
libproc-2 seems to fit, our second major re-work of the procps
library.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
After much reflection I've come to the conclusion that
displaying 3 decimal places (usually) when memory data
had been scaled is no longer optimal with today's ever
increasing amounts. And given that not all task memory
fields are the same widths, inconsistencies can easily
arise as illustrated and discussed in the issue below.
Instead of unilaterally reducing the number of decimal
places, this commit will sneak in such a change via an
existing configure option that was very likely unused.
The former 'disable-wide-memory' option has now become
'enable-wide-memory', which can be used if the current
behavior (3 decimal places) is preferred. Without that
option, whenever memory is scaled beyond KiB, just one
decimal place will be shown in Summary and Task areas.
And Task area field width will no longer be changed by
this revised configure option. Instead, all such field
widths will now be fixed at the former maximum values.
Reference(s):
https://gitlab.com/procps-ng/procps/issues/50
[ this patch has been adapted from the master branch ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the configure option --enable-harden-flags the CFLAGS and
LDFLAGS are manipulated to provide some hardening protection
to the binaries.
psmisc uses these flags on by default with no troubles, however
it doesn't have a library in it either.
References:
https://wiki.debian.org/Hardening
Historically LFS mattered only to open/read large files. A few programs
here use open/seek, but not generally on files that are large. However,
LFS also applies to stat which procps does in a bunch of places -- some
filesystems have 64bit inodes and attempts to do a 32bit stat will throw
an error.
Enable transparent LFS everywhere to avoid this.
It was probably always wrong to have a variable length
proc_t structure. This patch takes all remaining oomem
former suse only options and makes them unconditional.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The previous commit got rid of some but not all the library. The
format of it was a little odd with the library being explicitly
defined instead of letting autoconf do it for you.
The "usrbin_execdir" hack meant to install some binaries in /bin and
others in /usr/bin. However:
- It is very inflexible: not much control on the final directory name
and it is not possible to get rid of the usr/bin suffix without
patching the build system.
- It is hard to use: it requires configure to receive --exec_prefix=/
and other settings do not make much sense. It is not very obvious that
that setting needs to be passed and it takes a while to figure it out.
- It produces garbage with the default setup: the default prefix of
/usr/local ends up installing the binaries under /usr/local/usr/bin
which does not make any sense.
Furthermore, the requirement to split binaries in /bin and /usr/bin is
not that strong since some distributions adopted the /usr merge and so
would agree to just deploy all binaries to /usr/bin directly.
Distributions that would still like to split /bin from /usr/bin should
actually move binaries such as `ps` and `kill` to /bin after the install
of procps-ng is complete. After all, they are the ones responsible for
determining what are the binaries that need to be in the root partition
and that list depends on their early boot init scripts, so it is
possible that the list must be augmented with other binaries from this
package.
Therefore, I propose here to get rid of that hack and simply install all
the binaries to bindir instead, which solves the problems described
above and simplifies the build and install of procps-ng.
Tested that it builds and both `make check` and `make distcheck` work.
Tested that `make install` works and produces the expected tree, the
only difference being the absence of the bogus /usr/local/usr/bin
directory and now all binaries are merged into /usr/local/bin as
expected.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Otherwise, automake 1.14 will warn that this option will become the
default in an upcoming release, which will cause problems for the
procps-ng build.
Now that the automake rules were merged in the top level Makefile.am,
it is possible to enable "subdir-objects" without breaking the build or
the dist.
Tested that it builds and both `make check` and `make distcheck` work.
Tested that `make install` works and produces the same tree before and
after this change. Confirmed that binaries are also placed in the same
locations in the build tree.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
This will be required for subdir-objects, otherwise automake will have
problems with more than one Makefile.am having rules to build the same
files.
Tested that it builds and both `make check` and `make distcheck` work.
Tested `make install` and compared the tree with the one installed
before this commit, both installed the binaries to the same locations.
The binaries are also in the same location in the build tree (for
instance, ps/pscommand is still there.)
Checked the binaries for the correct libraries linked into them. Binary
sizes matched before and after this change.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
This suppresses the following warning from libtoolize 2.4.2:
libtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT'
Tested that this does not break the build and that both `make check` and
`make distcheck` continue working as expected.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
For over a decade top has used a startup configuration
mimicking the original redhat top. This decision dates
back to when the forked Sourceforge version was trying
to win over users in battles with that ancient kludge.
Will anybody deny that those defaults are coyote ugly?
Well, it is time that top presented a more modern look
at startup, providing that no saved rcfile exists. But
just in case some distro prefers that old, comfortable
look, there's the '--disable-modern-top' build option.
[ Pssst. With the widened memory fields it turns out ]
[ the 'Mem' default window had become almost useless ]
[ on an 80x24 terminal since %CPU & COMMAND were out ]
[ of view. So some other defaults were tweaked a bit ]
[ whether or not --disable-modern-top was specified. ]
Reference(s)
http://www.freelists.org/post/procps/tops-graph-mode-saga-continues,3
Signed-off-by: Jim Warner <james.warner@comcast.net>
The translated manpage generation has moved from scripts to
Makefiles. This asists with conditional building as well, no
need to regenerate the German pgrep man page if both
the original pgrep.1 and man-po/de.po is not changed.
My Makefile-fu fails me on producing a cross-product or double
iteration for languages and man pages. Until that is solved
each man page is explicitly built. No big deal but it doesn't
look elegant in the Makefile. Languages will be picked
up automatically if they are found in man-po, man-po/top or
man-po/ps
The README describes the three-step process for translating
the files, incase I forget or someone else wants to update them.
Library systemd-login offers possibility to display
name of a systemd slice unit for specific pid.
This patch adds output option "slice" which will
show name of systemd slice unit.
To maintain compatibility with non-systemd systems,
procps must be configured with --with-systemd option
to enable this option.
As the sysvinit becomes obsolete, some of the bundled tools
need to find a new home. The procps-ng project seems to be
the most suitable project for adopting the pidof tool.
This commit introduces a redesigned version of pidof
that satisfies the LSB requirements.
In corner cases the behaviour might differ from the former
one as the new version doesn't use any stat(2) calls.
The automake AM_SILENT_RULES macro is supported since automake 1.11
(which is required for procps). The silent functionality is enabled by
default, you can change it by:
./configure --disable-silent-rules
or
make V=1
Note that make still prints compiler errors, etc.
Signed-off-by: Karel Zak <kzak@redhat.com>
* don't duplicate default behavior with [enable_foo=$enableval]
* don't introduce things like disable_* variables
* use everywhere the same coding style
Signed-off-by: Karel Zak <kzak@redhat.com>
Previously the libselinux support was present
in the sources, but disabled with a preprocessor
condition (#if 0).
From now the libselinux support can be enabled with
the --enable-libselinux switch available
in the configuration script. That way is more
flexible than local patches modifying the condition
value from 0 to 1.
When summary & task area memory scaling was introduced
in release 3.3.6, the memory field widths were widened
slightly so unscaled KiB values could be provided more
consistently and scaled values (beyond MiB) could show
3 decimal places of precision. However, some users may
prefer the former widths/precisions for memory fields.
This commit will provide a build time configure option
to return top to those former defaults as a compliment
to a new %CPU & %MEM field precision configure option.
Reference(s):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707648
commit 21e550bc08
Signed-off-by: Jim Warner <james.warner@comcast.net>
When summary & task area memory scaling was introduced
in release 3.3.6, the percentage columns were expanded
to provide 3 decimal places of precision. In hindsight
that may have been overkill, making those columns more
of a distraction than useful, with just too much info.
This patch will revert those columns to the former one
decimal place. And as was true, that decimal point may
be sacrificed depending on the number of cpus present.
And, in case anyone might prefer additional precision,
a build option can provide it (--enable-wide-percent).
Reference(s):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707648http://www.freelists.org/post/procps/What-happened-to-my-top,1
commit 21e550bc08
Signed-off-by: Jim Warner <james.warner@comcast.net>
The earlier commit purporting to allow top to be built
in the absence of that dynamic linking library stopped
just a little short of the truth. So this will fix it.
Reference(s):
commit 5686877cd4
Signed-off-by: Jim Warner <james.warner@comcast.net>
Been a while since we ran a re-scan over the autotools files. This
change modernises the configure file. Not a great deal of changes
required to bring us up to date, autoscan doesn't understand our
optional things, which is fine.
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
commit 87ac6383bb
. 2) too-cold
commit 53fd7dd1ed
. 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>
Library systemd-login offers possibility to display
the name of the VM or container which process belongs to.
This patch adds output option "sd_machine" which will
show machine name or "-" when the name can not be determined.
To maintain compatibility with non-systemd systems,
procps must be configured with --with-systemd option
to enable this option.
Library systemd-login offers possibility to display
name of a systemd unit file for specific pid. Note that
not all processes are part of a system unit/service
(e.g. user processes, or kernel threads).
This patch adds output option "sd_unit" which will
show name of systemd unit or "-", when process does not
belong to any unit.
To maintain compatibility with non-systemd systems,
procps must be configured with --with-systemd option
to enable this option.
