This recipe takes longer time >20min when bitbake for package
write stage. When cross-verified for longer time duration, found
that do_check() stage taking 20min while other stages completes
before 6min.
This recipe gives only below two test binaries in the packages to
test (ptest: glibc-y2038-tests):
io/ftwtest
io/ftwtest-time64
The above test binaries are already included for testing in recipe
glibc-testsuite_2.39.bb.
It is by now well established that glibc itself works as it should,
that all affected 32 bit targets are configured to use 64 bit time_t,
and that any lingering y2038 issues are in components other than the c
library, and usually come from C programming mistakes (e.g. storing
timestamps in long). So this recipe seems to be redundant and
can be removed.
Review comments for fixing above longer time duration ended up in
removing this recipe as a proposal is below
https://lists.openembedded.org/g/openembedded-core/topic/112188476#msg214636
Removed lines having reference to glibc-y2038-tests in the files.
For master branch requested for integration and below is the link
https://lists.openembedded.org/g/openembedded-core/message/215655
(From OE-Core rev: b214cc84a922f7a3fb7ebbc501189ce25e8bd2bd)
Signed-off-by: rajmohan r <semc.2042@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The recipe originates from meta-y2038 where the name was not
confusing, but in oe-core it is.
(From OE-Core rev: 90bc7a66b08580207839fc6aafe1ac86c12981c5)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Additionally:
- drop pseudo from INSANE_SKIP for 32bit time API check
(pseudo passes the check; it's not clear where the issue may have been)
- move rust exceptions to the cargo class, as the problem
is common across the ecosystem, and needs to be fixed in the
libc crate.
(From OE-Core rev: d3d406bf636e579c17708b408e11c12d252533ee)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Until strace can handle the interface with glibc correctly with those flags,
disable there for now.
(From OE-Core rev: 5235ae1a14b71d42c1effff51e0289654bc7122a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Existing implementation required to list both specific problematic apis, and files that
use them: neither is necessary as both are seen in package_qa error messages, and
can cause excessive amount of exception lines, if there are too many files, or
they are installed in arch-specific locations. Also, the value of INSANE_SKIP
should be the test that needs to be skipped, and in this case it wasn't.
Also, all problematic recipes are now correctly listed.
(From OE-Core rev: e6ebd0c556dfc576a59f5755d97089a2a241f698)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It builds glibc source like other glibc recipes do,
and so the same problems occur.
(From OE-Core rev: 68b50d362ec61f27be818e40fcbb281d9bacf756)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This avoids adding a spurious space in TARGET_CC_ARCH when
GLIBC_64BIT_TIME_FLAGS is empty
(From OE-Core rev: 5d077129d8e849ce3a79285825231c642e79be70)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It needs to be fixed to honor _FILE_OFFSET_BITS before we can enable
64bit time_t
(From OE-Core rev: 206ab9522963aee471004d987181ed2f8363f1ad)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I meant to do this whilst merging but messed up the patches. This
file is a .inc file and should match the others.
(From OE-Core rev: d9398dfb0866a5be9ed09ae15902606fe11da2d2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
