Given a G5 scratch installed with FC 6, with two tweaks: - the select packages page gets the "desktop" option disabled, and don't bother to enable the "developer" option -> don't install gcc stuff initially - the kernel had to be hand installed and then, following http://sourceware.org/frysk/build/ install all the following: sudo yum install -y antlr jdom junit gcc-java gcc-c++ dejagnu libglade-java-devel libvte-java-devel automake xmlto transfig eclipse-ecj dogtail sharutils cvs audit-libs-devel binutils-devel results in a gcc that defaults to 32-bit but doesn't work; does work 64-bit: torreja$ gcc ~/tmp/fib.c In file included from /usr/include/features.h:352, from /usr/include/pthread.h:22, from /home/cygnus/cagney/tmp/fib.c:3: /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory torreja$ gcc -m32 ~/tmp/fib.c In file included from /usr/include/features.h:352, from /usr/include/pthread.h:22, from /home/cygnus/cagney/tmp/fib.c:3: /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory torreja$ gcc -m64 ~/tmp/fib.c /tmp/ccEGOgJf.o:(.text+0xf0): undefined reference to `pthread_create' /tmp/ccEGOgJf.o:(.text+0x17c): undefined reference to `pthread_join' /tmp/ccEGOgJf.o:(.text+0x284): undefined reference to `pthread_attr_setstacksize' collect2: ld returned 1 exit status torreja$ gcc -m64 ~/tmp/fib.c -lpthread torreja$ ./a.out I'm guessing that more RPMs are needed, but what, and why not install as part of pulling in the above? Poking shows that only glibc-devel.64 was sucked in by the above. $ rpm -qa --queryformat '%{NAME}.%{ARCH}\n' | grep glibc glibc-common.ppc glibc.ppc glibc.ppc64 glibc-headers.ppc glibc-devel.ppc64
Interesting. Unlike in bug 216967, this is a case where yum presumably _should_ have installed both versions of the package.
what was the command that pulled in the glibc-devel dep?
(In reply to comment #0) [...] > and then, following http://sourceware.org/frysk/build/ install all the following: > > sudo yum install -y antlr jdom junit gcc-java gcc-c++ dejagnu > libglade-java-devel libvte-java-devel automake xmlto transfig eclipse-ecj > dogtail sharutils cvs audit-libs-devel binutils-devel [...]
I've just run across this in a freshly installed RHEL5 (appeared to be 100% uptodate but I didn't install it originally). yum install glibc-devel fixed the problem. Probably there are two identical machines untouched since install if someone wants to have a look. I can't confirm that until its day time in MN once again though.
This is really a bug in the package, though -- it says that it requires glibc-devel and glibc-devel of the "best" arch was installed. If gcc is going to default to -m32, then it probably should require the appropriate glibc-devel. (In reply to comment #1) > Interesting. Unlike in bug 216967, this is a case where yum presumably _should_ > have installed both versions of the package. The difference is that in that case, there was an explicit request for a package (kernel) to be installed and thus all compat arches get installed. For a depsolve, you only need the package which provides the dep. Adding glibc-devel to the list of packages being installed here would "workaround" the problem, but it really seems that the requires for gcc aren't quite right.
Well, the primary broken thing is that on ppc and sparc where we really prefer 32-bit packages rpm shouldn't be preferring 64-bit packages. As gcc supports both -m32 and -m64 and really can work with either glibc-devel, depending on what options you use, I'm not really convinced it should require a particular arch of glibc-devel.
(In reply to comment #6) > Well, the primary broken thing is that on ppc and sparc where we really prefer > 32-bit packages rpm shouldn't be preferring 64-bit packages. This isn't the case though -- we have to prefer 64bit packages, otherwise, we don't get the right kernel and other things along those lines. > As gcc supports both -m32 and -m64 and really can work with either glibc-devel, > depending on what options you use, I'm not really convinced it should require > a particular arch of glibc-devel. And similarly, there's no way for yum to "know" unless things are expressed in the package.
No, the kernel is a special case (and in fact anaconda seems to have been getting that wrong too, recently).
FYI, (In reply to comment #5) > (In reply to comment #1) > > Interesting. Unlike in bug 216967, this is a case where yum presumably _should_ > > have installed both versions of the package. > > The difference is that in that case, there was an explicit request for a package > (kernel) to be installed and thus all compat arches get installed. I mention that a kernel was explicitly installed for completeness, and in the interest of full disclosure, only (it was to work around another installer bug). Installing a specific ppc64 kernel did not lead to the installation of any other packages. Per comment #0 and comment #3 glibc-devel was pulled in as part of that yum command. BTW, some of the other -devel packages I specified did pull in 32- and 64- bit versions automatically, wierd.
(In reply to comment #9) > Per comment #0 and comment #3 glibc-devel was pulled in as part of that yum > command. BTW, some of the other -devel packages I specified did pull in 32- and > 64- bit versions automatically, wierd. If you explicitly specify the package, all available arches will be installed. Basically, this all looks like it's working as intended and if we don't want to make gcc depend on a specific arch of glibc-devel, then you either need to a) explicitly request glibc-devel in this case (which since you're working from instructions we can update, that's not hard to change) or b) request glibc-devel.ppc after the fact on ppc.
If that's the position, then this needs clear documentation for end users on how one is to go about setting up a 32- x 64- environment.
That documentation wouldn't be part of gcc though.
I just ran into this with Fedora 7 plus updates. If nothing else, it seems like it'd be helpful to have a note in gnu/stubs.h explaining where stubs-32.h and stubs-64.h come from...
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.