From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) by mx.groups.io with SMTP id smtpd.web09.685.1623166828273850759 for ; Tue, 08 Jun 2021 08:40:28 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@linuxfoundation.org header.s=google header.b=aY5M/6kG; spf=pass (domain: linuxfoundation.org, ip: 209.85.208.180, mailfrom: mhalstead@linuxfoundation.org) Received: by mail-lj1-f180.google.com with SMTP id c11so27605120ljd.6 for ; Tue, 08 Jun 2021 08:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jJbabTHek8nSS2jkMh7aUKdrwGLIzyywUGMFBWxmI0c=; b=aY5M/6kGqg1nbtXLLemlVZ/EqCeBkjSl1J30Xb21ZM/KU8/Z2OrO36xhIJ5Z9Mr++g RCAlQ48eS6EEvFxlouCyRuiCXYDlegCXN51CvCABjbNkLdslVrKoCvmqSy4b6DNvQH9g SxXGikYbR65FkR5tOz07Qge/tK4znr0zW+bY4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jJbabTHek8nSS2jkMh7aUKdrwGLIzyywUGMFBWxmI0c=; b=DsAvX6UPaj5KnrgOsVEp6TbB7l1rNHeVxQLIlquqOnvhQi8GDglA8EP9/fR1ZVtmiw WTGNq52+ZR/aOYRXbdyOsAuBt40oIzOs8fkRFxyTklN4dJ0lUtBTrj+eD0jEX50vDCfx TvfvEmh2zmozt/B5nPzukhhQ0e44nAhy1BkToy9Hx73wEjVXLUai/2H/bTat4EhABD0O JGJrC640VCVwdxO2HTmDs+Kbl4uhjhorhZWz5xB3Ur2/5miABeZnlHCMEv5Zdy8f/nUF oviLm5FPqOa3t9CqCePxcahhIzfEkGmhWi7C9NJS3w7vpgm/dyaLdUmy1ngyz0kesz9/ 3wLQ== X-Gm-Message-State: AOAM533e3pTUAErV3F93xHhLDavIj7J8DXux+0cY2QzRT9PtdXRjSX1g FEvz2ngRWkvXwxh+8+wYQ848uWFGjOCfmZUXkxv51w== X-Google-Smtp-Source: ABdhPJzVZKJSY/HHMpzMKeX5W8N6zMJ2R7aup/VwZHWMzCW/IMaNdRDkgapDVK5vKpyT49Gm99FlmudbLkwpOURYj44= X-Received: by 2002:a2e:88da:: with SMTP id a26mr18916523ljk.214.1623166826252; Tue, 08 Jun 2021 08:40:26 -0700 (PDT) MIME-Version: 1.0 References: <20210604091458.1381144-1-alex.kanavin@gmail.com> <20210604091458.1381144-4-alex.kanavin@gmail.com> <1685B658849E960A.4717@lists.openembedded.org> <50a73766-dc52-0600-a6cd-7ab422030782@gmail.com> <7e56d093ba6c1390cec71ef3a362abe84ce735bb.camel@linuxfoundation.org> <2ac70a7b01743192ae4ec42b2b1eee18becde25d.camel@linuxfoundation.org> In-Reply-To: From: "Michael Halstead" Date: Tue, 8 Jun 2021 08:40:15 -0700 Message-ID: Subject: Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3 To: Alexander Kanavin Cc: Khem Raj , Bruce Ashfield , OE-core , Richard Purdie Content-Type: multipart/alternative; boundary="00000000000017241805c442fa27" --00000000000017241805c442fa27 Content-Type: text/plain; charset="UTF-8" I've rebooted centos8-ty-1 using the previous 4.18.0-240.15.1.el8_3.x86_64 kernel and kept it in the pool. I've paused centos8-ty-2 so it won't interfere with builds and left it at the current 4.18.0-305.3.1.el8.x86_64 kernel for testing. On Mon, Jun 7, 2021 at 11:04 AM Alexander Kanavin wrote: > On Mon, 7 Jun 2021 at 19:18, Khem Raj wrote: > >> > I added the needed packages to the CentOS workers. The compiled binary >> prints "rc=0" on the three CentOS workers. >> >> can we now try linking and running it against SDK built nativesdk-glibc ? >> > > Using the host libc won't show the issue, as it is old (2.28), isn't using > utimensat_time64 and goes straight to utimensat. > > With nativesdk-glibc, it still succeeds: > utimensat_time64(3, NULL, [{tv_sec=1, tv_nsec=2} /* > 1970-01-01T00:00:01.000000002+0000 */, {tv_sec=3, tv_nsec=4} /* > 1970-01-01T00:00:03.000000004+0000 */], 0) = 0 > > So we'd need to look into why the kernel accepts this, but rejects the > call from cmake. Any easy way to trace this? Just to repeat the failing one: > > 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) > > Alex > -- Michael Halstead Linux Foundation / Yocto Project Systems Operations Engineer --00000000000017241805c442fa27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've rebooted=C2=A0centos8-ty-1=C2=A0using the previou= s=C2=A04.18.0-240.15.1.el8_3.x86_64 kernel and kept it in the pool. I'v= e paused=C2=A0centos8-ty-2 so it won't interfere with builds and left i= t at the current 4.18.0-305.3.1.el8.x86_64 kernel for testing.=C2=A0
<= br>
On Mon,= Jun 7, 2021 at 11:04 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote:
On Mon, 7 Jun 2021 at 19:18, Khe= m Raj <raj.khem@= gmail.com> wrote:
> I added the needed packages to the CentOS workers. The comp= iled binary prints "rc=3D0" on the three CentOS workers.

can we now try linking and running it against SDK built nativesdk-glibc ?

Using the host libc won't show the i= ssue, as it is old (2.28), isn't using utimensat_time64 and goes straig= ht to utimensat.

With nativesdk-glibc, it still su= cceeds:
utimensat_time64(3, NULL, [{tv_sec=3D1, tv_nsec=3D2} /* 1= 970-01-01T00:00:01.000000002+0000 */, {tv_sec=3D3, tv_nsec=3D4} /* 1970-01-= 01T00:00:03.000000004+0000 */], 0) =3D 0

So we'= ;d need to look into why the kernel accepts this, but rejects the call from= cmake. Any easy way to trace this? Just to repeat the failing one:

utimensat_time64(AT_FDCWD, "../install/usr/local/lib= /cmake/assimp-4.1/assimp-config.cmake", [{tv_sec=3D1622966723, tv_nsec= =3D6319439026193432576}, {tv_sec=3D1622966579, tv_nsec=3D178400536923094384= 64}], 0) =3D -1 EINVAL (Invalid argument)

Alex
=


--
Michael Halstead
Linux Foun= dation / Yocto Project
Systems Operations Engineer
--00000000000017241805c442fa27--