psrinfo check in configure requires eval on Solaris
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
RPM |
Fix Committed
|
Medium
|
Jeff Johnson |
Bug Description
I'm back to working on building RPM on x86_64-
configure from both CVS (as of 20131016) and rpm-5.4.12 has issues on Solaris when trying to determine the # of processors:
=== INSTALLATION PARAMETERS ===
checking root's primary group... root
checking how to determine NCPUS... psrinfo: processor |: Invalid argument
psrinfo: processor egrep: Invalid argument
psrinfo: processor 'on-line': Invalid argument
psrinfo: processor |: Invalid argument
psrinfo: processor wc: Invalid argument
psrinfo: processor -l: Invalid argument
psrinfo: processor |: Invalid argument
psrinfo: processor sed: Invalid argument
psrinfo: processor -e: Invalid argument
psrinfo: processor 's+^: Invalid argument
psrinfo: processor *++': Invalid argument
`psrinfo | egrep 'on-line' | wc -l | sed -e 's+^ *++'` ()
The issue is that the NCPUS_COMMAND that's defined in the case statement isn't actually being eval'ed by the backticks.
There are two possible fixes:
1) just insert an "eval" in front of $NCPUS_COMMAND in the backticks. That does the trick for Solaris, and it doesn't seem to cause any issues on Linux either. I can't easily test freebsd or darwin.
2) instead of defining the command in the case and then running the command after the case, just expand what the case statement does, actually gathering the results there too.
I chose option #1 for the attached patch, but I could easily provide a patch that instead does option #2.
Changed in rpm: | |
milestone: | 5.4.13 → 5.4.14 |
Applied.
The real problem here is that commands executed on the build machine,
particularly at the level of NCPUS, are mostly irrelevant to client installs.
The further issue is that NCPUS is a "soft" command: its trivial to conceive
a need for uniprocessor builds on a multi-processor machine, i.e. the actual
NCPUS is most irrelevant/naive to how the NCPUS value is actually used.
Portability for commands determining per-os NCPUS is a trip through the
whorehouse of uglix as well.
OTOH, there are well known library API's (unlike scripts) for determining NCPUS,
and rpm already "knows" NCPUS portably using those library API's. SO the eventual
fix will be devising a better paradigm for configuring rpmbuild than "make -j$NCPUS"
and just rip out all of this hysterical baggage.
Meanwhile the patch is perfect for now, hurts nothing, will be in rpm-5.4.14. Thanks!