Re: problem with interpreter

Ross Burton <ross@...>

On Wed, 12 Jan 2022 at 18:34, swhite <r.spencer.white@...> wrote:
I need to include an old open source project named judy for a legacy
utility dependency. The recipe I have so far is listed at the end of this email. The
build host is 64bit linux, I'm using dunfell and the MACHINE I'm build for is "genericx86-64".
The issue I'm seeing is when compiling judy, it builds and then executes a
binary named "JudyLTablesGen" as part of the process. However the execution
fails with:

/bin/sh: ./JudyLTablesGen: No such file or directory
This is a classic problem with software that doesn't consider
cross-compilation (and even when building for a similar architecture,
like genericx86-64 on an x86 host, you're cross-compiling in Yocto).

The makefiles generate a binary that it expects to be able to run.
This is a bad assumption as you're cross-compiling: that binary needs
to be built with the host compiler (BUILD_CC) instead. However, the does this:

JudyLTables.c: JudyLTablesGen.c
$(CC) $(INCLUDES) $(AM_CFLAGS) @CFLAGS@ -o JudyLTablesGen
JudyLTablesGen.c; ./JudyLTablesGen

A non-upstreamable fix would be to simply change that line to
$(BUILD_CC) $(BUILD_CFLAGS) $(BUILD_LDFLAGS) -o JudyLTablesGen [...].
As the project is dead, an upstreamable fix isn't useful.

Whilst I'm here that FILESEXTRAPATHS_prepend is redundant, and the
source of Judy looks like fairly typical autoconf so you can remove
your do_configure and just 'inherit autotools', this will also pass
the correct host/build/target flags and so on.

Also note that a more recently maintained fork appears to be at


Join to automatically receive all group messages.