On Fri, May 16, 2014 at 3:19 PM, Tilghman Lesher <[email protected]> wrote: > On Fri, May 16, 2014 at 1:54 PM, Will Drewry <[email protected]> wrote: >> (diverging slightly) >> >> On Fri, May 16, 2014 at 11:30 AM, Tilghman Lesher <[email protected]> >> wrote: >>> On Fri, May 16, 2014 at 10:07 AM, Howard White <[email protected]> wrote: >>>> Could someone give me a short course on why it is one executes these steps: >>>> >>>> ./configure as root >>>> make as a user >>>> make install as root >>>> >>>> ???? >>>> >>>> I'm confused... >>>> >>>> Howard >>> >>> You don't necessarily need to run configure as root, but there are >>> some tests, especially for daemons which start as root, which need the >>> additional privileges to execute. For example, in Asterisk, I've >>> written a test to check whether one may provide a bitfield longer than >>> 1024 bits to the select(2) kernel call. This functionality is >>> necessary to see if we can practically have more than 1024 file >>> handles open, or if things would simply not work in that case. The >>> problem is that you cannot have a file handle numbered greater than >>> 1023 by default in any process, so you have to increase the available >>> number of file handles in order to run that test. >> >> I think that this case may have an unprivileged solution for most >> users -- though it is a fine example of the idea of needing enhanced >> capabilities in order to test kernel/system support! >> >> By default, a process can have a maximum of files open as defined by: >> /proc/sys/fs/file-max (or sysctl fs.file-max) > > This only works on Linux.
Yup - but it's very common to cover all dependent requirements in configure. E.g., if the kernel is Linux, then make sure subsequent dependencies X, Y, and Z all function as expected. > Configure scripts are typically designed to > run on multiple platforms, not always Linux. In fact, one of the > guidelines for writing configure tests is to ALWAYS test the actual > functionality you seek, rather than trying to grab system versions and > attempting to extrapolate from there. > > Thus, it's better to increase the limit to some value beyond any > standard limit and attempt to use that. I don't believe there is a good file-max cross-platform solution, so you'd end up check each one to know whether the test will fail out of hand. (E.g., kern.max-files from FreeBSD iirc). I wouldn't ever suggest that merely checking the max file count would be a strong enough indicator to be sure some other kernel functionality was present though -- like the select limitations. I would just make these tests pre-requisites for the select test. >> However, many environments include limitations enforced via resource >> limits [ulimit(3)/*rlimits] for an interactive user process tree. >> Bash (and pretty much every shell) can help check those with a simple: >> >>> ulimit -nS # soft limit >> 1024 >> >>> ulimit -nH # hard limit >> 4096 > > What platform are you doing this on? I just tried it on Ubuntu 12.04 > and those extensions to ulimit don't work. I mentioned in the other reply that I reversed the order - sorry! That said, rlimit support of some sort should exist on most POSIX-ish (1003.1) platform: http://pubs.opengroup.org/onlinepubs/009695399/functions/getrlimit.html >> So if I were writing a configure stanza for something like this, I >> would check sysctl, then call getrlimit(RLIMIT_NOFILE,...) and tell >> the user they need to either increase their limits before running >> configure (e.g., via /etc/security/limits.conf or whatever) or run as >> a privileged user that can override resource limit enforcement. >> Alternatively, you can try the above hack to maximize the ulimit >> setting and then only fail if that can't be done. > > Another alternative (which we've done in Asterisk, due to the need to > run on cross-compiled architectures) is to delay the test until > runtime and decline to run if the support is lacking. Yeah - cross-compiling is a pain that way :/ cheers! will -- -- You received this message because you are subscribed to the Google Groups "NLUG" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en --- You received this message because you are subscribed to the Google Groups "NLUG" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
