[CentOS] Latest x86_64 != latest i386 packages?

Sat Jul 1 22:57:14 UTC 2006
Bart Schaefer <barton.schaefer at gmail.com>

On 7/1/06, Jim Perrin <jperrin at gmail.com> 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.