[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: building print/libcups, cannot set ulimit on centos stream
Date: Mon, 25 Jan 2021 08:54:26 -0500
From: Greg Troxel <gdt%lexort.com@localhost>
| The easier thing is to understand where this is coming from in libcups,
| and patch it out or deal with it. If libcups upstream is using a
| ulimit flag not even specfied by the upcoming POSIX spec, that feels
| like a bug, certainly if the build fails because of it.
I'm not sure why -m wasn't included in the new set of POSIX options, perhaps
some systems don't support the underlying limit - but this is (I think)
the only common option (ie: all shells try to support it and give it the
same meaning) that wasn't included.
So, I wouldn't worry too much about it. Unless there is a need to build
on a system where -m doesn't work, there is no common shell that I know
of that doesn't support it (at least on NetBSD, and I'd assume on most
supported target systems).
FWIW, POSIX is adding -H -S and -a (as generic options, not tied to specific
limits) and -c -d -n -s -t and -v (to -f which is the one which has long
existed) as options for specific limits. Aside from -m, the other
limits which exist tend to be either not supported, or named or processed
differently, on different shells. Eg: -p (pipe size) is not supported
by bosh, yash or zsh, and counts multiples of 512 in bash, rather than
simply bytes everywhere else it is supported. Our -r (threads) is -T
in bash zsh and ksh93 (and not existing in many other shells).
Main Index |
Thread Index |