Bug 167733 - either x86_64 or i386 versions installed, but not both
either x86_64 or i386 versions installed, but not both
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
4
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-07 14:10 EDT by Dimitri Maziuk
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-07 14:26:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dimitri Maziuk 2005-09-07 14:10:02 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux) KHTML/3.4.2 (like Gecko)

Description of problem:
I'm filing this against gcc because there's no libstdc++-devel in component   
list, and I'm not sure whose problem this really is: rpm? Anyway, I've 2 AMD   
machines with "development" packages installed. On one, compiling   
 #include <fstream>   
 int main() { return 0; }   
failed with error messages about bits/c++config header file. I finally tracked   
it down to libstdc++-devel: only i386 version was installed, but not x86_64.   
   
I then checked the other machine: only x86_64 rpm is installed on that one,   
compiling the above with "g++ -m32" fails with the same errors.  
  
I'm assuming the problem may affect other packages -- libraries that come in  
both x86_64 and i386 flavours -- as well.   
 
Also, it looks like "yum list libstdc++-devel" 

Version-Release number of selected component (if applicable):
libstdc++-devel

How reproducible:
Sometimes

Steps to Reproduce:
1. Install FC4 develoment group.  
2. List installed libstdc++-devel packages.  
3. See if both x86_64 and i386 versions are installed.  
    

Actual Results:  (on the 2nd machine) 
Installed Packages 
libstdc++-devel.x86_64                 4.0.1-4.fc4            installed 
Available Packages 
libstdc++-devel.i386                   4.0.1-4.fc4            updates-released 
 

Expected Results:  both should be installed 

Additional info:
Comment 1 Dimitri Maziuk 2005-09-07 14:17:11 EDT
Oops. That should've been  
 ''Also, it looks like "yum list libstdc++-devel" won't list both versions as 
"installed" for some reason.'' 
 
Comment 2 Jakub Jelinek 2005-09-07 14:26:53 EDT
I don't see how that's gcc's fault.  If you don't install libstdc++-devel.x86_64,
you obviously can't compile C++ stuff with gcc-c++.x86_64.
If you choose to install gcc-c++ in FC4 installer, it will DTRT,
libstdc++-devel.x86_64 will be installed and so will yum update unless you
force it to use a specific arch, at which point it is admin's fault.
Comment 3 Dimitri Maziuk 2005-09-07 16:20:06 EDT
Look, I just ran "yum update" on one of these boxes: 
 
[root@hino ~]# yum list libstdc++-devel 
... snip ... 
Installed Packages 
libstdc++-devel.i386                     4.0.1-4.fc4          installed 
Available Packages 
libstdc++-devel.x86_64                   4.0.1-4.fc4          updates-released 
 
[root@hino ~]# yum install libstdc++-devel 
... snip ... 
  Installing: libstdc++-devel              ######################### [1/2] 
  Cleanup   : libstdc++-devel              ######################### [2/2] 
 
Installed: libstdc++-devel.x86_64 0:4.0.1-4.fc4 
Complete! 
 
[root@hino ~]# yum list libstdc++-devel 
... snip ... 
Installed Packages 
libstdc++-devel.x86_64                 4.0.1-4.fc4            installed 
Available Packages 
libstdc++-devel.i386                   4.0.1-4.fc4            updates-released 
 
[root@hino ~]# g++ -m32 -o stupidtest stupidtest.cc 
In file included from /usr/include/features.h:337, 
                 
from /usr/lib/gcc/x86_64-redhat-linux/4.0.1/../../../../include/c++/4.0.1/x86_64-redhat-linux/bits/os_defines.h:39, 
                 
from /usr/lib/gcc/x86_64-redhat-linux/4.0.1/../../../../include/c++/4.0.1/x86_64-redhat-linux/bits/c++config.h:39, 
                 
from /usr/lib/gcc/x86_64-redhat-linux/4.0.1/../../../../include/c++/4.0.1/iosfwd:44, 
                 
from /usr/lib/gcc/x86_64-redhat-linux/4.0.1/../../../../include/c++/4.0.1/ios:43, 
                 
from /usr/lib/gcc/x86_64-redhat-linux/4.0.1/../../../../include/c++/4.0.1/istream:44, 
                 
from /usr/lib/gcc/x86_64-redhat-linux/4.0.1/../../../../include/c++/4.0.1/fstream:44, 
                 from stupidtest.cc:1: 
/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or 
directory 
 
[root@hino ~]# g++ -o stupidtest stupidtest.cc 
[root@hino ~]#  
 
Please explain to me what The Right Thing is, in your definition: not being 
able to compile 32-bit c++ code? 
 
Like I said, on the other machine "it's" DTRT was to install i386 package and 
not the x86_64. 
 
I also said I wasn't sure who "it" was and I filed the bug against gcc because 
it was the closest thing to libstdc++-devel on the list -- it could be 
something in how yum/rpm handle "dual-arch" of AMD64, for all I know. 
 
All I can tell you is regular installation of C++ devel stuff results in a 
system that can compile C++ code to either native or "-m32" format, but not 
both. 
 
Comment 4 Jakub Jelinek 2005-09-07 17:10:03 EDT
It would be helpful if you mentioned the exact error message before.
Missing gnu/stubs-32.h is a user error.  If you want to build 32-bit programs,
you of course need glibc-devel.i386 installed.
Comment 5 Dimitri Maziuk 2005-09-07 17:47:41 EDT
OK, now we're getting somewhere. So the obvious question is, then, why wasn't 
glibc-devel.i386 installed with libstdc++-devel (or gcc?) -- if you can't run 
"gcc -m32", your gcc installation is b0rked, so there should be a dependency 
somewhere. 
 
So it looks like I somehow ended up with libstdc++-devel.i386 installed 
instead of .x86_64. I've no idea how that happened since I wasn't forcing arch 
when I installed stuff, but let's call it a glitch and leave it at that -- I 
have spent too much time on this already. 
 

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