bitbake -c menuconfig swupdate fails: scripts/kconfig/mconf: No such file or directory

[David Antliff]

Hi,

I'm working in a PetaLinux 2021.2 environment, which is really Yocto (branch gatesgarth), and I'm setting up SWUpdate for my target, also on its branch gatesgarth (744d6b9).

I've got the swupdate layer integrated, it builds with the default config, and I've got libubootenv included so fw_printenv etc works. When I boot QEMU or the target, I can see Swupdate v2021.04.0 starting on the console, registering handlers.

Where I'm stuck is here, with menuconfig:

$ bitbake -c menuconfig swupdate

make -C ...build/tmp/work/cortexa72-cortexa53-xilinx-linux/swupdate/2021.04-r0/g>
  GEN     ...build/tmp/work/cortexa72-cortexa53-xilinx-linux/swupdate/2021.04-r0>
scripts/kconfig/mconf  Kconfig
make[3]: scripts/kconfig/mconf: No such file or directory
make[3]: *** [...build/tmp/work/cortexa72-cortexa53-xilinx-linux/swupdate/2021.0>
make[2]: *** [...build/tmp/work/cortexa72-cortexa53-xilinx-linux/swupdate/2021.0>
make[1]: *** [Makefile:97: sub-make] Error 2
make: *** [Makefile:19: all] Error 2
Command failed.
Press any key to continue...

menuconfig works with other components, but for some reason not this one. I looked in the ...build/tmp/work/cortexa72-cortexa53-xilinx-linux/swupdate/2021.04-r0/build/ directory and there's a scripts/kconfig/mconf:

$ file scripts/kconfig/mconf
scripts/kconfig/mconf: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /scratch/jenkins-BUILDS-eSDK-2021.2_stable-pipeline-build-89_VersalFullPrime/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2, BuildID[sha1]=3c3eb48055e050b49fb9ee2cd7ef4350d992545c, for GNU/Linux 3.2.0, not stripped

I searched for various combinations of the error messages and there were some similar (but not quite the same errors) involving libncurses5 and libncurses5-dev however I have ensured I have those packages installed and the error persists.

Other bitbake targets like "bitbake -c menuconfig u-boot-xlnx" work fine.

Any suggestions on how I could begin to debug or work around this issue, please?

-- David.

[David Antliff]

On Monday, July 4, 2022 at 5:08:45 PM UTC+12 David Antliff wrote:

[snip]

menuconfig works with other components, but for some reason not this one. I looked in the ...build/tmp/work/cortexa72-cortexa53-xilinx-linux/swupdate/2021.04-r0/build/ directory and there's a scripts/kconfig/mconf:

$ file scripts/kconfig/mconf
scripts/kconfig/mconf: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /scratch/jenkins-BUILDS-eSDK-2021.2_stable-pipeline-build-89_VersalFullPrime/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2, BuildID[sha1]=3c3eb48055e050b49fb9ee2cd7ef4350d992545c, for GNU/Linux 3.2.0, not stripped

The odd thing about this binary, which is located at build/tmp/work/cortexa72-cortexa53-xilinx-linux/swupdate/2021.04-r0/build/scripts/kconfig/mconf, is that if I try and run it, I just get:

$ ./mconf
bash: ./mconf: No such file or directory

It's an x86-64 ELF file, so why can't bash (or make) execute it?

$ ldd mconf
    linux-vdso.so.1 (0x00007ffd493ec000)
    libncursesw.so.5 => [redacted]/build/tmp/work/cortexa72-cortexa53-xilinx-linux/swupdate/2021.04-r0/recipe-sysroot-native/usr/lib/libncursesw.so.5 (0x00007f6801000000)
    libtinfo.so.5 => [redacted]/build/tmp/work/cortexa72-cortexa53-xilinx-linux/swupdate/2021.04-r0/recipe-sysroot-native/usr/lib/libtinfo.so.5 (0x00007f6800c00000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f68009d8000)
    /scratch/jenkins-BUILDS-eSDK-2021.2_stable-pipeline-build-89_VersalFullPrime/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f680143d000)

$ stat mconf
  File: mconf
  Size: 179976        Blocks: 352        IO Block: 4096   regular file
Device: 10308h/66312d    Inode: 24802606    Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/   david)   Gid: ( 1000/   david)
Access: 2022-07-11 15:51:20.189219790 +1200
Modify: 2022-07-11 15:51:20.145222291 +1200
Change: 2022-07-11 15:51:20.145222291 +1200
 Birth: 2022-07-11 15:51:20.133222973 +1200

I can't get much out of strace from it:

$ strace ./mconf
execve("./mconf", ["./mconf"], 0x7ffeec8539b0 /* 69 vars */) = -1 ENOENT (No such file or directory)
strace: exec: No such file or directory
+++ exited with 1 +++

But weirdly, that's not what I see from strace if I give it an actual made-up filename:

$ strace ./mconf-made-up
strace: Can't stat './mconf-made-up': No such file or directory

Also:

$ readelf -a mconf | grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libncursesw.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [libtinfo.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

$ readelf -a mconf | grep interpreter
      [Requesting program interpreter: /scratch/jenkins-BUILDS-eSDK-2021.2_stable-pipeline-build-89_VersalFullPrime/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2]

Is that long path a problem? It doesn't exist on my system. Versal is a Xilinx (PetaLinux) thing. Has mconf been built incorrectly in this environment?

There's another binary in the same directory, conf, and that shows this instead, where /lib64/ld-linux-x86-64.so.2 does exist on my machine:

$ readelf -a conf | grep interpreter
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

Any idea what's going on here? This is starting to look a lot like a PetaLinux issue, but it's a problem I only see with swupdate.

-- David.

 

 

[David Antliff]

Alright, sorry for the noise, I think this is definitely a PetaLinux issue, because if I run this manually:

make -C /[redacted]/build/tmp/work/cortexa72-cortexa53-xilinx-linux/swupdate/2021.04-r0/git \

      O=/[redacted]/build/tmp/work/cortexa72-cortexa53-xilinx-linux/swupdate/2021.04-r0/build/. menuconfig

It works! Also, the resultant mconf looks much happier:

$ readelf -a scripts/kconfig/mconf | grep interpreter
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

But if I run petalinux-config -c swupdate, which also ends up running that make command-line (which is where I got it from in the first place), but with who-knows-what environment, it breaks as described earlier.

-- David.

[Stefano Babic]

Hi David,

On 04.07.22 07:08, David Antliff wrote:
> Hi,
>
> I'm working in a PetaLinux 2021.2 environment, which is really Yocto

> (branch /gatesgarth/),

I confess I give up here - nice you found what happens. However,
"petalinux" is not Yocto, it is one of the way vendors try to lock in
customers without working with community. It is not easy to update to a
new version of Yocto when it is released, and well, gatesgarth has
already reached EOL. And I do not mention kernel lock-in with tons of
patches that are not merged into mainline.

Frankly speaking, I had several projects to "depetalinize", letting the
product to use vanilla / standard Yocto environment independently from
Vivado. I was quite sure it depends on petalinux, bitbale -c menuconfig
works flawlessly under YP.

Best regards,
Stefano Babic

> and I'm setting up SWUpdate for my target, also

> on its branch /gatesgarth/ (744d6b9).

> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/CAAC8%3Dj32Seo4ja1_rbJniOdNv7doOk1zqTg445ZN92xTe22jWg%40mail.gmail.com
> <https://groups.google.com/d/msgid/swupdate/CAAC8%3Dj32Seo4ja1_rbJniOdNv7doOk1zqTg445ZN92xTe22jWg%40mail.gmail.com?utm_medium=email&utm_source=footer>.


--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[ayoub...@googlemail.com]

Hi,

I must agree with Stefano here that Petalinux is the worst Yocto distro I ever seen (shame on you Xilinx) but swupdate menuconfig is working:

$ petalinux-build -c swupdate -x menuconfig

Best

[David Antliff]

On Tue, Jul 12, 2022 at 9:42 PM Stefano Babic <sba...@denx.de> wrote:

Hi David,

Hi Stefano,

 

On 04.07.22 07:08, David Antliff wrote:
> I'm working in a PetaLinux 2021.2 environment, which is really Yocto
> (branch /gatesgarth/),

I confess I give up here - nice you found what happens. However,
"petalinux" is not Yocto, it is one of the way vendors try to lock in
customers without working with community. It is not easy to update to a
new version of Yocto when it is released, and well, gatesgarth has
already reached EOL. And I do not mention kernel lock-in with tons of
patches that are not merged into mainline.

Frankly speaking, I had several projects to "depetalinize", letting the
product to use vanilla / standard Yocto environment independently from
Vivado. I was quite sure it depends on petalinux, bitbale -c menuconfig
works flawlessly under YP.

Yes, I totally understand - and if it were entirely up to me I'd be using vanilla Yocto also. Hopefully one day...

That said, I did try 'devtool modify swupdate' and then 'bitbake -c menuconfig swupdate' and I actually get the same problem, just with slightly different source/build paths. So somehow the interpreter is getting set to some weird Jenkins path.

But for now I'm just running the command, seeing the error, then copy/pasting the 'make' command-line displayed and it works like that :)

-- David.

[David Antliff]

On Tue, Jul 12, 2022 at 10:04 PM 'ayoub...@googlemail.com' via swupdate <swup...@googlegroups.com> wrote:

I must agree with Stefano here that Petalinux is the worst Yocto distro I ever seen (shame on you Xilinx) but swupdate menuconfig is working:

$ petalinux-build -c swupdate -x menuconfig

Not for me sadly - see first email.

But never mind, I have a workaround. See last email :)

I'm no apologist for Xilinx, but I can see why they thought it "useful" to wrap Yocto (to handle their proprietary elements like FSBL and FPGA workflow), but perhaps it could have been done in a better way.

Actually this is the one area (packaging the proprietary stuff) where I'm not sure how to proceed in "depetalinuxing" my project - but that's probably a topic for a different mailing list.

Cheers,

-- David.

[ayoub...@googlemail.com]

Hi David,

in all your mails you used bitbake command which is not fully supported in petalinux, as I wrote you should use petalinux-build instead of bitbake !

[David Antliff]

> From: 'ayoub...@googlemail.com' via swupdate <swup...@googlegroups.com>

> in all your mails you used bitbake command which is not fully supported in petalinux, as I wrote you should use petalinux-build instead of bitbake !

Yes, thank you, I am aware of this. In fact I have explicitly enabled
support in PetaLinux for direct use of bitbake/devtool via the
workflow advised by Xilinx, which is why I am using those commands.
Apart from this one case with swupdate, they actually work just fine,
and that's how I'm used to using Yocto anyway.

Xilinx do support "dropping down" to them in PLNX 2021.2, at least
their docs suggest as much.

Of course, I use the petalinux-* commands for day to day activity. I'm
just using these yocto commands to try and debug this particular
issue, to remove as much of PetaLinux from the question as possible.
What I'm left with now is that there's something about the environment
that is setting ld's --dynamic-linker option to a weird path when
compiling mconf, and this happens with both petalinux-build and when
running bitbake directly, but only with the swupdate recipe.

I'm only posting about this on this mailing list because it doesn't
happen with any other recipe in my project.

But as of right now, my workaround running 'make' directory works
fine, and I'm time-poor, so I can just use that. The true cause will
remain a mystery for now :)

-- David.