GNU bug report logs -
#9396
make fails with undefined reference to '__sched_cpucount'
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9396 in the body.
You can then email your comments to 9396 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#9396
; Package
coreutils
.
(Sun, 28 Aug 2011 23:17:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Feuerbacher, Alan" <AFeuerbacher <at> ALLEGROMICRO.com>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Sun, 28 Aug 2011 23:17:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Howdy,
I'm trying to compile coreutils-8.12 in a Dell Xeon workstation environment that runs Redhat 5 (RHEL5). After some time, make fails with:
+verbatim+
../lib/libcoreutils.a(nproc.o): In function `num_processors_via_affinity_mask':
/home/afbacher/GCC/coreutils-8.12/lib/nproc.c:137: undefined reference to `__sched_cpucount'
collect2: ld returned 1 exit status
make[3]: *** [nproc] Error 1
make[3]: Leaving directory `/home/afbacher/GCC/coreutils-8.12/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/afbacher/GCC/coreutils-8.12/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/afbacher/GCC/coreutils-8.12'
make: *** [all] Error 2
-verbatim-
I tracked the problem down to the fact that the RHEL5 system uses /lib64/libc.so.6 which apparently is version 2.5 of the GNU C Library, but this version does not contain "__sched_cpucount" - whatever that is. Apparently only version 2.6 and later contain this stuff.
One problem is that I'm not the sysadmin for this system, and I don't think this can be updated without breaking a lot of other stuff. How do I get around this? I'm only trying to compile a bunch of programs for my own use, not for the entire system.
I'm actually trying to compile glibc-2.14 for various reasons, along with a bunch of other basic GNU software (like gcc-4.6.), and I found that when glibc's installer installs various coreutils programs like rm, as soon as these get installed the programs quit working because of incompatible ABI's and such. That's why I thought I needed to install the latest coreutils.
I'm probably missing something badly, but I more than a bit confused about the order in which the various sets of software need to be installed in order to keep it all consistent.
One thing I've done is to make my $PATH contain the path to my newly built programs. That's why, when the glibc installer installs rm and such, various other programs quit working, because there's a lot of interdependence. So what's my best approach with all this?
Alan Feuerbacher
[Message part 2 (text/html, inline)]
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#9396
; Package
coreutils
.
(Mon, 29 Aug 2011 00:53:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 9396 <at> debbugs.gnu.org (full text, mbox):
On 08/28/11 14:59, Feuerbacher, Alan wrote:
> I tracked the problem down to the fact that the RHEL5 system uses /lib64/libc.so.6
> which apparently is version 2.5 of the GNU C Library,
> but this version does not contain "__sched_cpucount" - whatever that is.
> Apparently only version 2.6 and later contain this stuff.
It sounds like you're compiling with glibc 2.6 headers but linking
to glibc 2.5. If so, that'd be a definite no-no; you need to configure
and build with <= 2.5 headers if you're going to link with 2.5.
I expect that it's the 2.6 headers that #define CPU_COUNT and bring
in a reference to __sched_cpucount.
Reply sent
to
Jim Meyering <jim <at> meyering.net>
:
You have taken responsibility.
(Tue, 13 Sep 2011 09:49:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
"Feuerbacher, Alan" <AFeuerbacher <at> ALLEGROMICRO.com>
:
bug acknowledged by developer.
(Tue, 13 Sep 2011 09:49:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 9396-done <at> debbugs.gnu.org (full text, mbox):
tags 9396 notabug
thanks
Paul Eggert wrote:
> On 08/28/11 14:59, Feuerbacher, Alan wrote:
>> I tracked the problem down to the fact that the RHEL5 system uses
>> /lib64/libc.so.6
>> which apparently is version 2.5 of the GNU C Library,
>> but this version does not contain "__sched_cpucount" - whatever that is.
>> Apparently only version 2.6 and later contain this stuff.
>
> It sounds like you're compiling with glibc 2.6 headers but linking
> to glibc 2.5. If so, that'd be a definite no-no; you need to configure
> and build with <= 2.5 headers if you're going to link with 2.5.
>
> I expect that it's the 2.6 headers that #define CPU_COUNT and bring
> in a reference to __sched_cpucount.
Thanks for the report.
Since we haven't heard back from you, I presume that
Paul's diagnosis was correct and have thus closed this bug.
If not, please let us know.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 11 Oct 2011 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 13 years and 334 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.