Thread (26 messages) 26 messages, 5 authors, 2021-10-04

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

From: Mittal, Anuj <hidden>
Date: 2021-09-29 01:12:00

Did we find out the reason why this was happening? I have started
getting this error on Centos-8 while building hardknott.

https://autobuilder.yoctoproject.org/typhoon/#/builders/63/builds/4045

Thanks,

Anuj

On Wed, 2021-06-16 at 23:45 +0100, Richard Purdie wrote:
On Sun, 2021-06-06 at 21:51 +0200, Alexander Kanavin wrote:
quoted
On Sun, 6 Jun 2021 at 01:10, Richard Purdie
[off-list ref] wrote:
quoted
I tried again with the autobuilder, still fails:

https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3516

so whatever it is, it is still "live".

I did some digging. The issue happens when:
- host is centos8
- SDKMACHINE is i686 (e.g. cmake is 32 bit)

Then there's a failing syscall attempting to set file times:
utimensat_time64(AT_FDCWD, "../install/usr/local/lib/cmake/assimp-
4.1/assimp-config.cmake",
[{tv_sec=1622966723, tv_nsec=6319439026193432576},
{tv_sec=1622966579, tv_nsec=17840053692309438464}], 0) = -1
EINVAL (Invalid argument)

On latest Fedora, there's no issue:
utimensat_time64(AT_FDCWD, "../install2/usr/local/lib/cmake/assimp-
4.1/assimp-config.cmake",
[{tv_sec=1623002886, tv_nsec=6369724778172907520},
{tv_sec=1623002886, tv_nsec=17839174083007217664}], 0) = 0

utimensat_time64 only appeared with 5.1 kernels, however, 4.18 should
be returning ENOSYS in that case
probably?
I hacked up a quick test bit of code (which makes assumptions 
about 32 bit):

#include <unistd.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>

struct timespec64 {
    long long           tv_sec;                 /* seconds */
    long long           tv_nsec;                /* nanoseconds */
};

int main() {
  int fd = open("foo", O_RDWR | O_CREAT, 0644);
  write(fd, "foo", 3);
  struct timespec64 times[2] = {};
  times[0].tv_sec = 1622966723;
  times[0].tv_nsec = 631943;
  times[1].tv_sec = 1622966579;
  times[1].tv_nsec = 178400;
  int rc = syscall(SYS_utimensat_time64, fd, NULL, &times[0], 0);
  printf("rc=%d\n", rc);
  close(fd);
  return rc;
}

built with "gcc -m32 test-syscall.c -o test" and run with "strace
./test".
This works on all the systems I tried it in. As does:


  times[0].tv_sec = 1;
  times[0].tv_nsec = 2;
  times[1].tv_sec = 3;
  times[1].tv_nsec = 4;

however if you set (and ignore the compiler warning):

  times[0].tv_sec = 1622966723;
  times[0].tv_nsec = 6319439026193432576;
  times[1].tv_sec = 1622966579;
  times[1].tv_nsec = 17840053692309438464;

then you see EINVAL on the centos system but not on my ubuntu one. It
will
do that until you reduce the values of tv_nsec right now. So it seems
most 
systems accept large tv_nsec values but the Centos one does not.

I think tv_nsec may be being clamped to LONG_MAX of 4 bytes but should
be 
a LONG_LONG_MAX of 8 bytes on a 32 bit since the field is a 64 bit
long.

Michael: Hopefully that gives you something to raise with them?

Cheers,

Richard






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153046):
https://lists.openembedded.org/g/openembedded-core/message/153046
Mute This Topic: https://lists.openembedded.org/mt/83304703/3616702
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe:
https://lists.openembedded.org/g/openembedded-core/unsub [anuj.mittal@intel.com
]
-=-=-=-=-=-=-=-=-=-=-=-
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help