From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 Description of problem: rpm command exits with segfault (badly handled SIGILL in fact, see additonnal informations below) when processing sha1 signature. rpm -q 'installed_pkg' -> buggy rpm -q 'not_installed_pkg' -> not buggy (no sha1 processing) In fact, with such a bug, I suppose that installing RH 8.0 on i386 cpu computer is propably impossible. I did the install on a i686 computer, avoiding all *.i686.rpm packages (install from harddrive) and put back the harddrive on the i386 pc. So I face the bug only now. Please read the following explanations: sha1Process() from beecrypt library in the rpm source package (not the beecrypt package !) assumes arch=i686 This is done at build time, not at runtime. The default sha1Process(), written in C, is all-x86-cpu compliant whereas the asm version contains 'bswap' instructions that are i486+ cpu compatible only. If you rebuild the package from srpms on a i686 host with '--target i386-foo-linux' , this won't fix the problem because this option is not used by 'configure' at %build stage, and beecrypt will be build for i686 anyway. To realy fix this, you need to change the rpm.spec file, adding the argument '--host=%{_target_platform}' to the 'configure' call in the %build section and rebuild the package. There is perhaps a better way to make it works... but that's the one I found. Version-Release number of selected component (if applicable): rpm-4.1-1.06 How reproducible: Always Steps to Reproduce: 1.any 'rpm -q already_installed_package' 2.or any 'rpm -qa' 3. Actual Results: segfault and doesn't do what's expected of course Expected Results: a working command ! Additional info: Well, all above are informations from what is making rpm command crash. But there is an underlying bug, possibly more severe, and not easy to track (at least for me :-) ) All this is ix86 related only. In librpmio, RPMClass() tries to determine the kind of cpu. First thing is to identify i386 cpus. This is (very poorly) done this way: signal(SIGILL,model3) followed by a 'cpuid' instruction, which is only 486+ Of course this raise a SIGILL on i386 cpus, indicating that it is an i386. It is not very clean, but it works. Hunting for this bug, I've found many documentation on the web explaining how to do it *cleanly*. Surprising... The problem is that if any other SIGILL is raised during the execution, model3() is called, and registers are restored with the value they had during RPMClass() call where model3() where supposed to branch. Of course this is nonsense if SIGILL is not raised during RPMClass So this is the bad ugly SIGILL handling, leading to SIGSEGV. I think that I shall also open a bug report for this...
A few things I forgot. The same bug exists in RH 7.3 / rpm 4.0.4 but never revealed (for me) because the sha1Process was never called (no sha1 signed packages installed). If you build a simple programm calling only sha1Process() and linked to librpmio, you get a real SIGILL because SIGILL is not handled with model3(). True for RH7.3 and RH8.
Yes, i486 is the earliest x86 model supported by rpm. You can fix the bswap problem by editing beecrypt/sha1opt.h to disable assembly speedups. You can avoid the cpuid by using rpm-4.0.5 (iirc, otherwise backport) to use a config.guess output-like string in /etc/rpm/platform. Packages at ftp://ftp.rpm.org/pub/rpm/test-4.0.5.
Well, that is exactly the "too easy" answer I was afraid to get. Where does the information saying that 486+ cpu are requiered come from ? The only information from rpm.org is * Linux - Sparc/Intel/PowerPC/Alpha/m68k/SGI Nothing more precise. But this might be not up to date ? as 99% of the website. I know how much writing documentation is boring, but there is not any information about this cpu type restriction ANYWHERE. But if it's true, what is {arch} done for ? rpm-xx-yy.i386.rpm should not exist ! Why not considering building 2 rpm: one for i386 and one for i486+ , or more likely: one for i3/4/586 and one for i686 ? There is even more simple. Couldn't we treat this '2 versions' issue directly in the beecrypt library ? specialy seeing this (first lines of rpm's CHANGES file) 4.0.4 -> 4.1: - loosely wire beecrypt library into rpm. This would solve the problem about sha1() dynamic calls but (I suppose) not the /bib/rpm case, staticaly linked. Then again, "at least", a simple rebuild of the rpm-4.1 package, using the already installed, right architecture, beecrypt(-devel) version wouldn't require any change in the way to build the package for different architectures.
Not it isn't an "easy" answer. I support platforms that I have access to, and i386 is not one of those platforms. I cannot justify the time supporting i386, there's almost noone who is using anymore. I can (and have) told you how to "fix" the problems. Building per-arch packages adds yet another dimension to an already complicated build matrix, now upwards of 20 different platform/versions, and increasingly rapidly. i386 is insufficiently high priority. FWIW, Red Hat stopped supporting i386 several years ago. Just because packages have an "i386" string does not mean that the hardware arch is supported.