I am building some software (swupdate) that has the traditional 'kbuild' (kconfig / menuconfig) mechanism, and thus has an intermediate binary mconf
that it builds before it brings up the text-menu system.
I'm using a third-party "productivity layer" tool to invoke the menuconfig (PetaLinux, a wrapper around Yocto), but the binary that results is not usable:
$ scripts/kconfig/mconf
bash: scripts/kconfig/mconf: No such file or directory
I figured out that this weird behaviour is due to the following:
$ readelf -a scripts/kconfig/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]
Note the long path to a ld-linux-x86-64.so
, which I don't have on my system in that location. This path looks like it's leaked into the build from the PetaLinux environment, somehow.
What it should look like is:
$ readelf -a scripts/kconfig/mconf | grep interpreter
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
Incidentally, I got that binary by building mconf
manually, with a command like this:
make -C <path/to/source> O=<path/to/build> menuconfig
...
HOSTCC scripts/kconfig/mconf.o
...
Anyway, that's all details, and my actual question is this - where can I find information about how the "program interpreter" is set by the compiler or linker? Where do you think it's going wrong? Is there an environment variable that can affect this behaviour?