Bug 90168
Summary: | rpm command segfault on i386 cpu due to mischosen arch when rpm (included beecrypt lib) was build | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Eric Thomas <bugzilla> |
Component: | rpm | Assignee: | Jeff Johnson <jbj> |
Status: | CLOSED WONTFIX | QA Contact: | Mike McLean <mikem> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 8.0 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-05-05 14:17:55 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Eric Thomas
2003-05-04 13:15:50 UTC
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. |