Bug 216980 - /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory
/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
6
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Bill Nottingham
bzcl34nup
: Reopened
Depends On:
Blocks: 173278 217536
  Show dependency treegraph
 
Reported: 2006-11-22 18:32 EST by Andrew Cagney
Modified: 2014-03-16 23:04 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 12:55:21 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 Andrew Cagney 2006-11-22 18:32:11 EST
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
Comment 1 David Woodhouse 2006-11-23 02:27:38 EST
Interesting. Unlike in bug 216967, this is a case where yum presumably _should_
have installed both versions of the package.
Comment 2 Seth Vidal 2006-11-23 11:46:37 EST
what was the command that pulled in the glibc-devel dep?
Comment 3 Andrew Cagney 2006-11-23 12:17:52 EST
(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
[...]
Comment 4 Steve Whitehouse 2006-11-28 05:26:41 EST
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.
Comment 5 Jeremy Katz 2006-11-28 11:19:28 EST
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.
Comment 6 Jakub Jelinek 2006-11-28 11:29:53 EST
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.
Comment 7 Jeremy Katz 2006-11-28 11:44:45 EST
(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.
Comment 8 David Woodhouse 2006-11-28 11:59:55 EST
No, the kernel is a special case (and in fact anaconda seems to have been
getting that wrong too, recently).
Comment 9 Andrew Cagney 2006-11-28 12:10:09 EST
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.
Comment 10 Jeremy Katz 2006-11-30 10:37:16 EST
(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.
Comment 11 Andrew Cagney 2006-11-30 10:44:26 EST
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.

Comment 12 Jakub Jelinek 2006-12-01 07:44:34 EST
That documentation wouldn't be part of gcc though.
Comment 13 Elliot Lee 2007-09-04 15:30:08 EDT
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...
Comment 14 Bug Zapper 2008-04-04 00:52:51 EDT
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
Comment 15 Bug Zapper 2008-05-06 12:55:19 EDT
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.

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