Bug 191850 - missing files
missing files
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: David Cantrell
Bill Nottingham
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2006-05-15 22:38 EDT by Albert Cahalan
Modified: 2014-03-16 22:59 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-19 16:51:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Albert Cahalan 2006-05-15 22:38:28 EDT
Description of problem:

As distributed by the upstream developers, the valgrind package
compiles itself to support both 32-bit and 64-bit. The x86-64
package for FC5 is missing many critical files related to 32-bit
support, and installs the 64-bit files in a location that does
not agree with the choice made by upstream.

Please quit needlessly patching and breaking upstream's source.

Version-Release number of selected component (if applicable):
I think it was 3.1 or 3.x.1 (whatever FC5 uses now)

How reproducible:

Steps to Reproduce:
1. install all valgrind packages and 32-bit dev tools
2. gcc -m32 helloworld.c
3. valgrind ./a.out
Actual results:
does not find the x86-linux files, and thus does not run

Expected results:
runs without complaint

Additional info:

Everything else seems to work for 32-bit development.
I can use gcc, etc., so the stuff is installed.
Comment 1 Jakub Jelinek 2006-05-16 02:58:47 EDT
If you want to trace 32-bit programs, you need to install both valgrind*.i386.rpm
and valgrind*.x86_64.rpm.
Comment 2 Albert Cahalan 2006-05-16 03:09:35 EDT
Why is valgrind special in a bad way?

I have no such problems with gcc.
There are no such problems with upstream valgrind.
I never saw an option to install 32-bit support.

Thus, I conclude that the package is broken.
Comment 3 Albert Cahalan 2006-05-16 03:18:25 EDT
Also, obviously:

To the extent that the packages overlap, I want the result to be
deterministic. It's not OK to have binaries that might be 32-bit
or 64-bit depending on which package I install first.

I would expect such packages to conflict. They damn well should.
There are already bug reports related to a failure to conflict.
(user uninstalls one of the two, leaving binaries supposedly
provided by the other RPM but really not, and now the needed
libraries have gone missing)

In any case... where is it? On the i386 CD-ROMs??? Of course I
did not burn those. No i386 RPM is offered to me.

I ended up using a web browser and rpm2cpio. I'm definitely
not about to mess with installing a wrong-arch RPM that
fails to mention that it conflicts with the native RPM.
Comment 4 Jakub Jelinek 2006-05-16 03:23:12 EDT
In what bad way?
valgrind handles 32-bit binaries on x86_64 by having a set of 32-bit programs
that handle it.  Packaging them in *.x86_64.rpm is against all FC packaging
guidelines, plus would precluse 64-bit only installs if valgrind is installed.
Furthermore, the 32-bit binaries from x86_64 binaries are inferior to those
from a pure 32-bit build, due to defficiencies in valgrind configury.
The only problem is apparently that valgrind*.i386.rpm is not included in
x86_64 composes, so reassigning to distribution, so that both 32-bit and 64-bit
valgrind rpms are composed on x86_64.

The packages obviously don't conflict, the driver (/usr/bin/valgrind) will be
installed for the preferred arch (and even if it is not, the 32-bit one will
DTRT too) and the backend binaries are in separate arch path, so they don't
Comment 5 Bill Nottingham 2006-05-16 16:26:03 EDT
Assigning to rel-eng.
Comment 6 Jesse Keating 2006-05-17 11:29:09 EDT
I'm not exactly sure what rel-eng is supposed to do with this.
Comment 7 Bill Nottingham 2006-05-17 16:14:48 EDT
From comment #4:

The only problem is apparently that valgrind*.i386.rpm is not included in
x86_64 composes, so reassigning to distribution, so that both 32-bit and 64-bit
valgrind rpms are composed on x86_64.
Comment 8 Albert Cahalan 2006-05-17 22:32:28 EDT
Starting from a fairly normal x86-64 DVD install with the development
tools selected:

a. gcc does both 64-bit and 32-bit (appears to be 1 gcc and 2 libgcc)
b. strace does both 64-bit and 32-bit (appears to be 2 packages)
c. if I recall right, gdb also manages to handle both
d. valgrind only does 64-bit

One of these things is not like the others...

As far as I can tell, there isn't any way to get 32-bit support from
the x86-64 DVD or even from the x86-64 updates on the web.

Fixes, from best to worst:

a. package the tool as the upstream developers intended (duh)
b. make a special i386 rpm with just the extra files
c. tell users to install from upstream source
d. put the i386 rpm on the x86-64 DVD/web, despite file conflicts

If combined packaging as intended by the valgrind developers "is against
all FC packaging guidelines", then obviously the packaging guidlines fail
to take this case into account. No surprise; valgrind is an odd case.
Fix the guidelines to ensure sanity.
Comment 9 Jesse Keating 2006-05-19 16:51:18 EDT
Added to multi-lib.

Note You need to log in before you can comment on or make changes to this bug.