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
Makefile.am 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
https://github.com/netdata/libjudy.

Ross