Bug 167733
Summary: | either x86_64 or i386 versions installed, but not both | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dimitri Maziuk <dmaziuk> |
Component: | gcc | Assignee: | Jakub Jelinek <jakub> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-09-07 18:26:53 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
Dimitri Maziuk
2005-09-07 18:10:02 UTC
Oops. That should've been ''Also, it looks like "yum list libstdc++-devel" won't list both versions as "installed" for some reason.'' 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. 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. 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. 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. |