From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.smtp-ext.broadcom.com (relay.smtp-ext.broadcom.com [192.19.232.172]) by mx.groups.io with SMTP id smtpd.web08.10236.1607707404649314986 for ; Fri, 11 Dec 2020 09:23:25 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@broadcom.com header.s=dkimrelay header.b=TIAbcJq8; spf=permerror, err=parse error for token &{10 18 %{i}._ip.%{h}._ehlo.%{d}._spf.vali.email}: invalid domain name (domain: broadcom.com, ip: 192.19.232.172, mailfrom: scott.branden@broadcom.com) Received: from [10.136.13.65] (lbrmn-lnxub113.ric.broadcom.net [10.136.13.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by relay.smtp-ext.broadcom.com (Postfix) with ESMTPS id D787422566; Fri, 11 Dec 2020 09:23:22 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 relay.smtp-ext.broadcom.com D787422566 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=broadcom.com; s=dkimrelay; t=1607707403; bh=6NEZUsZwlET1wZJY4wGKvLxeXa9tkiFp6UxEwWfoUUs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=TIAbcJq8JYetHYh1pbqhwFMdwTvLP3Wm/R7X0wlk0WDht3eudmRfkhHE1Em2cn7E7 NTY3wtQGiw4SlqwRLZTm9eGI8+S1XUSaGicAT3HwtEWkq6IdS2H0LzsFMMnWmlioEx sd3MYthFDh6B1p3/QaSZOjr1ARCJyCJxZ4dfeqT4= Subject: Re: [OE-core] commit breaks menuconfig on upstream kernel "cml1.bbclass: Handle ncurses-native being available via pkg-config" To: Nathan Rossi , Richard Purdie Cc: Andrey Zhizhikin , OE-core References: <6de3791839a669b2c4fad3c347045a38e412a89d.camel@linuxfoundation.org> From: "Scott Branden" Message-ID: <48cfd598-2ca3-7e35-f62e-163d7547fb71@broadcom.com> Date: Fri, 11 Dec 2020 09:23:21 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-CA Could we have the commit reverted if a fix is not imminent? On 2020-12-03 10:22 p.m., Nathan Rossi wrote: > On Fri, 4 Dec 2020 at 14:58, Richard Purdie > wrote: >> On Fri, 2020-12-04 at 10:53 +1000, Nathan Rossi wrote: >>> On Fri, 4 Dec 2020 at 08:31, Andrey Zhizhikin >>> wrote: >>>> Hello Scott and Nathan, >>>> >>>> On Thu, Dec 3, 2020 at 7:18 PM Scott Branden via >>>> lists.openembedded.org >>>> wrote: >>>>> >>>>> On 2020-12-02 4:19 p.m., Nathan Rossi wrote: >>>>>> On Thu, 3 Dec 2020 at 05:17, Scott Branden < >>>>>> scott.branden@broadcom.com> wrote: >>>>>>> Hi Nathan, >>>>>>> >>>>>>> Your commit: >>>>>>> "cml1.bbclass: Handle ncurses-native being available via pkg- >>>>>>> config" >>>>>>> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=master-next&id=ce447d70df386ca55ce1672478b245851556374e >>>>>>> >>>>>>> breaks bitbake menuconfig when using the upstream kernel. >>>>>> Interesting. The purpose of the commit was to actually fix that >>>>>> exact >>>>>> use case since previously the mainline kernel menuconfig was >>>>>> relying >>>>>> on hardcoded paths to the host ncurses libraries. >>>>>> >>>>>> Would you be able to provide the error messages you are getting >>>>>> (and >>>>>> anything else that can help to reproduce the failure), because >>>>>> I am >>>>>> not able to reproduce any failures with a mainline kernel, >>>>>> linux-yocto >>>>>> (with and without the below mention patch) or with other >>>>>> projects that >>>>>> are using cml1 (e.g. u-boot). >>>>>> >>>>>>> It only works with the linux-yocto kernel due to this >>>>>>> workaround which is not upstream. >>>>>>> If you revert this commit in linux-yocto menuconfig will not >>>>>>> work in linux-yocto: >>>>>>> "menuconfig,mconf-cfg: Allow specification of ncurses >>>>>>> location" >>>>>>> https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/scripts/kconfig/mconf-cfg.sh?h=v5.8/standard/base&id=1714a5ad9cf61f4d0f4b8432f327cca2998aba77 >>>>>> This change should not be required to have menuconfig working >>>>>> when >>>>>> pkg-config is used. >>>>>> >>>>>>> Seems like your commit needs to be reverted or a change made >>>>>>> to work with the upstream kernel. >>>>>>> Or, the linux-yocto change needs to actually be >>>>>>> upstreamed. I submitted it and the upstream maintainer >>>>>>> questioned why the change is needed: >>>>>>> https://lore.kernel.org/lkml/CAK7LNATD0J3C_mFrXAju8-WmdCmrPmRFn7Um0yebnfL-_zcu8w@mail.gmail.com/ >>>>>> The problem is if it was accepted, every kernel prior to its >>>>>> inclusion >>>>>> would need to be patched, as well as other projects (u-boot, >>>>>> busybox). >>>>>> This makes supporting menuconfig using that change for kconfig >>>>>> generically problematic. This is why the pkg-config solution is >>>>>> preferable. >>>> As I've already said before I had similar issues with doing >>>> menuconfig >>>> kernel task. I took a deeper look and actually found out that the >>>> recipe-sysroot-native/usr/lib/pkgconfig/ncursesw.pc in the kernel >>>> recipe build folder contained the absolute path to the ld, which >>>> for >>>> me was taken from the SSTATE_MIRROR produced on the CI system. >>>> >>>> The string inside ncursesw.pc looked like this (note the -Wl, >>>> --dynamic-linker): >>>> Libs: -L${pcfiledir}/../../../usr/lib -Wl,--enable-new-dtags >>>> -Wl,-rpath-link,${pcfiledir}/../../../usr/lib >>>> -Wl,-rpath-link,${pcfiledir}/../../../lib >>>> -Wl,-rpath,${pcfiledir}/../../../usr/lib >>>> -Wl,-rpath,${pcfiledir}/../../../lib -Wl,-O1 >>>> -Wl,--allow-shlib-undefined >>>> -Wl,--dynamic-linker=/teamcity/work/c3acfc3a6f255dcb/build- >>>> output/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 >>>> -lncursesw -ltinfo >>>> >>>> I then manually changed it to match the path on my local PC, and >>>> menuconfig went totally fine after that. >>>> >>>> Nathan, >>>> I tend to believe this issue is not caused directly by the patch >>>> committed, but rather by the fact that pkg-conf files do contain >>>> absolute paths pulled from shared state. At least this is what I've >>>> observed for my setup. >>> That is indeed an issue with uninative/sstate, likely because >>> UNINATIVE_LOADER (which put into BUILD_LDFLAGS) is not covered by the >>> sstate pack/unpack path rewriting. But uninative already handles >>> rewriting interp as part of its sstate unpack function, maybe it >>> needs >>> to be updated to replace instances of LDFLAGS as well? Perhaps >>> Richard >>> has an opinion on this. >> I'd say that: >> >> a) .pc files are assumed to be correct and sstate is therefore probably >> not relocating paths in them >> >> b) paths like that should be triggering warnings about build paths in >> the .pc file. It might not be as sysroot-uninative is a bit of a >> special case we probably don't currently test for? > Just looking in the sysroot, it appears that for the kernel at least, > ncurses and python sysconfigdata are the only cases of the uninative > sysroot path being kept. Also the buildpath checks are only done for > package_qa and so are skipped for native correct? Should that be > improved so that native also does the buildpath checks? > >> c) that flags should be unneeded, they'd be in BUILD_LDFLAGS if we >> needed them >> >> So I'm guessing we probably need to tweak the .pc file to better handle >> this corner case. Most libs don't inject LD_FLAGS into their .pc file >> that I know of... > Yes it looks like ncurses is unnecessarily adding LDFLAGS to the .pc. > Patching ncurses should resolve this problem. > > Thanks, > Nathan