On 7/1/06, Jim Perrin <jperrin@xxxxxxxxx> wrote:
> Is this really correct? Yes, because you're mixing repositories. The -34 version comes from the fasttrack repository while the -24 version is in the general repository.
Aha. Yes, I do have the fasttrack repository enabled on the i386 machine; I had forgotten about that. However, it's the x86_64 machine where the perl problem occurs.
How is the build machine set up? Are you mixing i386 and x86_64 packages?
No, there are no i386 packages on the x86_64 machine, and only clamav and pine are from the rpmforge repository; the rest is straight CentOS. schaefer[125] rpm -qa | grep i386 schaefer[126]
> I'm trying to recompile zsh in the first place because the "limit" > command doesn't work on the x86_64 system, so the SRPM build appears > to have incorrectly preprocessed sys/resource.h and I wanted to track > down the details before filing a bug report. How does the limit command not work for you on x86_64?
It does absolutely nothing. Note that in zsh the "limit" and "ulimit" (not "unlimit") commands are distinct, though they can both be used to change the same settings. Here's the x86_64 machine: schaefer[117] ulimit -a cpu time (seconds) unlimited file size (blocks) unlimited data seg size (kbytes) unlimited stack size (kbytes) 10240 core file size (blocks) 0 resident set size (kbytes) unlimited processes 28663 file descriptors 1024 locked-in-memory size (kb) 32 address space (kb) unlimited file locks unlimited 1024 819200 schaefer[118] limit schaefer[119] limit coredumpsize 0 limit: no such resource: coredumpsize schaefer[120] Now here's the i386 machine: schaefer[502] ulimit -a cpu time (seconds) unlimited file size (blocks) unlimited data seg size (kbytes) unlimited stack size (kbytes) 10240 core file size (blocks) unlimited resident set size (kbytes) unlimited processes 32763 file descriptors 1024 locked-in-memory size (kb) 32 address space (kb) unlimited file locks unlimited 1024 819200 schaefer[503] limit cputime unlimited filesize unlimited datasize unlimited stacksize 10MB coredumpsize unlimited memoryuse unlimited maxproc 32763 descriptors 1024 memorylocked 32kB addressspace unlimited maxfilelocks unlimited schaefer[504]
Perhaps rather than rebuilding (and thereby introducing possible new variables that we cannot duplicate) you could provide us the steps to duplicate your problem and we can all work the issue.
I'm one of the zsh developers, and have been for about 15 years now. I know how the zsh build process is supposed to work. One part of it is to preprocess /usr/include/*/resource.h with an awk script to generate a new header that is used in the zsh build. The exact list of files handed to the awk script is determined by the configure script. The only way for the limit command to have lost all resources is if that awk pass went wrong -- probably because zsh's configure script did not look in /usr/include/asm-x86_64, which is possible if the same SRPM was used for both i386 and x86_64 rpmbuilds. What I intended to determine was whether this is a zsh configure bug that always occurs when compiling on this platform, or an apparent RPM build issue. However, I'm not an expert with the modern perl-based autoconf; it's been a long time since I wrote an autoconf script from scratch. _______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
