I filed a bug report
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7081
I also proposed a fix. The fix is quite safe, it does not affect glibc build,
only modifies the testing script glibc-testing.inc.
Incidentally, I believe there is a tiny bug in glibc-testing.inc:
fgrep tcbootstrap ${B}/config.make > ${B}/configparms
should be
fgrep tcbootstrap ${B}/config.make >> ${B}/configparms
Otherwise the just entered comments in configparms get immediately wiped-out.
Juro
Subject: Re: [OE-core] Problems running glibc test suite...
From: [email protected]
Date: Tue, 9 Dec 2014 09:39:55 -0800
CC: [email protected]
To: [email protected]
On Dec 9, 2014, at 9:08 AM, Juro Bystricky <[email protected]> wrote:I
tried to run the glibc test suite and encountered various problems.
I build glibc as a part of core-image-minimal with libgcc and libstdc++,
both additional libraries are needed by the glibc test suite.
By far most tests run just fine, but there are several tests that fail
to build at all. The offenders are:
/elf/tst-unique3cc
/elf/tst-unique4cc
/elf/tst-unique3lib.cc
/elf/tst-unique3lib2.cc.
They all fail with an error:
fatal error: cstdio: No such file or directory
#include <cstdio>
The obvious reason is that the c++ header files were not found by the g++.
g++ was invoked with -nostdinc flag, and in that case the path to system include
files must be specified explicitly.
The failed build is a consequence of a series of unfortunate events.
First, when building the glibc for the first time, configure cannot find g++
compiler at all. config.log states:
line 1594: arm-poky-linux-gnueabi-g++: command not found
configure:3165: $? = 127
Secondly, the g++ (which is not found) is then used to determine the location
of the
include headers, resulting in
CXX_SYSINCLUDES=''
Thirdly, even if g++ is found (it is found when re-building glibc, see below),
the algorithm used to detect the CXX_SYSINCLUDES does not seem to work and
the headers are not detected. I "fixed" this by adding the following to
git/configure:
@@ -5184,6 +5197,14 @@
test "x$cxxheaders" != x &&
CXX_SYSINCLUDES="$CXX_SYSINCLUDES -isystem $cxxheaders"
done
+ if test -z "$CXX_SYSINCLUDES"; then
+ cxxversion=`$CXX -dumpversion`
+ cxxmachine=`$CXX -dumpmachine`
+ CXX_SYSINCLUDES=" -isystem $sysheaders/c++/$cxxversion \
+-isystem $sysheaders/c++/$cxxversion/$cxxmachine"
+ { $as_echo "$as_me:${as_lineno-$LINENO}: guessing CXX_SYSINCLUDES:
$CXX_SYSINCLUDES" >&5
+$as_echo_n "guessing CXX_SYSINCLUDE: $CXX_SYSINCLUDES... " >&6; }
+ fi
fi
fi
After the core-image-minimal is built, by the time the test suite is run, g++
is present,
but CXX_SYSINCLUDES is still not correct (unless the "fix" above is applied).
However,
not all c++ tests require c++ headers, so some will build correctly. I tested
the "fix"
successfully with qemux86-64, qemumips and qemuarm.
(qemuarm exposed some additional problems though).
The "fix" is just a proof of concept: with correct CXX system header paths all
the offending programs build correctly. But this "fix" only works when
re-building
glibc after the core-image-minimal is built.
The g++ compiler is not needed for glibc at all, it is only needed to build
some of the tests in the testsuite. Probably worth noting is that glibc cannot
DEPEND on
g++ due to circular dependencies.
thats right. glibc is built using a bootstapped cross compiler where we disable
c++ support. This is to solve the catch-22 that glibc and gcc have. hence the
reason why you miss most of c++ probes.
The proper way to fix this would be to initialize CXX_SYSINCLUDES before
building/running the test suite
and not before building the glibc.
A suitable place for this seems to be recipes-core/glibc/glibc-testing.inc
yes. Running the test suites should be done after gcc-cross is built and
staged. I would not prefer to doubly build glibcthats just waste of build time.
Any thoughts?
Thanks
Juro
-- _______________________________________________Openembedded-core mailing
[email protected]http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
