現象が発生しているレシピはluaというプログラムになります。

luaファイルをコンパイルするため、luacというプログラムを
nativeツールとして生成しています（lua-nativeとして指定）

このとき、実機が32bitのため32bitとして動作するluacファイルの
生成が必要となりますが、開発ホストPCが64bitのため64bit対応の
luacファイルが生成されるようです。

そこで、native用luacファイル生成時のコンパイルオプションに-m32を
付けコンパイルしたところ、do_compile時に生成されたluac
ファイルは問題なかったのですが、do_installでimage下に
生成されたluacファイルではluacファイルが動作しないという
現象となっています。

ホストが64bitのところに32bitのプログラムを生成、動作させようとし
ているからだと思いますが、本対応が必要なプログラムがluaだけ
のため、uninativeをdisableにして対応できないかと考えていました。

disableにできない場合は開発ホストで64bit、32bit対応のものを構築
したいのですが、その方法を教えていただければと思います。

すみません、伝わりにくい文章だったので再度概要書かせていただきます。

実機で動作させるAというアプリケーションがluaスクリプトを参照する仕組みになっており、
そのluaスクリプトのビルドにluacを使用します。

このために、lua自体のレシピに修正を加えています。
レシピ内で、
EXTRA_OEMAKE = "'CC=${CC} -fPIC' 'MYCFLAGS=${CFLAGS} -DLUA_USE_LINUX -fPIC' MYLDFLAGS='${LDFLAGS}'"
EXTRA_OEMAKE_pn-lua-native = "'CC=${CC} -fPIC' 'MYCFLAGS=${CFLAGS} -DLUA_USE_LINUX -fPIC -m32' MYLDFLAGS='${LDFLAGS} -m32'"
と記述して、lua-nativeの生成時だけm32オプションを使うような書き方をしています。

これは、luaのレシピでluaとluacが生成されますが、
lua : これ自体を実機(armターゲット)で動作させるため、オプションを特に変更せずにビルドしたい
luac : 実機に組み込むスクリプトをビルドするために使うので、m32のオプションを着けて開発環境(x86)向けのバイナリを生成したい
という複雑な使い方をしようとしているからです。

これでbitbakeを実行すると、lua-nativeはEXTRA_OEMAKE_pn-lua-nativeでビルドされるのですが、
do_compileで生成されたluacのバイナリと、do_installでimage下に配置されるluacのバイナリで、
共有ライブラリの依存関係に差異があります。

[do_compileしたときに生成されたluacのlddの結果](使用したい結果)
linux-gate.so.1 (0xf776f000)
libm.so.6 => /lib32/libm.so.6 (0xf76d2000)
libdl.so.2 => /lib32/libdl.so.2 (0xf76cd000)
libreadline.so.7 => /lib32/libreadline.so.7 (0xf7683000)
libc.so.6 => /lib32/libc.so.6 (0xf74cb000)
/lib/ld-linux.so.2 (0xf7771000)
libtinfo.so.5 => /lib32/libtinfo.so.5 (0xf74a8000)

[do_installによってimage下に置かれたluacのlddの結果](失敗してしまう結果)
linux-gate.so.1 (0xf778b000)
libm.so.6 => /lib32/libm.so.6 (0xf76e9000)
libdl.so.2 => /lib32/libdl.so.2 (0xf76e4000)
libreadline.so.7 => /lib32/libreadline.so.7 (0xf769a000)
libc.so.6 => /lib32/libc.so.6 (0xf74e2000)
/hogehoge/poky/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib/ld-linux.so.2 (0xf778d000)　<--　ここ
libtinfo.so.5 => /lib32/libtinfo.so.5 (0xf74bf000)

手元では、luaのビルド後、do_installによって配置されたluacのバイナリを、
do_compileで生成された「使用したい結果」のほうに手動で差し替えることで狙ったrootfsが生成できるところまで確認しています。

上記の際の原因がuninativeにあるようだと判断し、本件の最初に質問させていただいた方法でuninativeを止めたところ
狙った動作(do_compileしたものがdo_installで正しく配置される)になった次第です。

以上が概要で、いただいた質問への返答としては、

> lua自体のレシピではなく、luaのソースファイルをluacでバイトコードにコンパイルしたファイルを
> ターゲットにインストールするためのレシピを作成したいということでしょうか？
lua自体のレシピを修正しています。luaのソースファイルをluacでバイトコードにコンパイルする際に、
自身が狙って生成したluac(do_compile時)なら成功するのですが、実際にはbitbake実行中に、
luaのソースファイルをコンパイルしようとするとエラーになって止まっており、
確認するとluaのソースファイルが参照しているluacの中身が変わっている、という現象です。

よろしくお願いいたします。

アドバイスありがとうございます。
静的なlinkを用いた方法は試していなかったので、手元の環境で試してみました。

試したのは以下です。
EXTRA_OEMAKE_pn-lua-native = "'CC=${CC} -fPIC' 'MYCFLAGS=${CFLAGS} -DLUA_USE_LINUX -fPIC -m32' MYLDFLAGS='${LDFLAGS} -m32 -static'"
↑static付けてます。

これで再トライすると、
ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality in `/hogehoge/lib32/libc.a(strcmp.o)` can not be used when making an executable; recompile with -fPIE and relink with -pie
となり、glibcの再コンパイルをしないと、手元の構成では無理そうな感じです。

glibcの再コンパイルまで含むと、他のモジュールへの影響が大きくなるので、この方法は見送っています。

前回の回答でいただいた「なかなか設定が見いだせておりません」というところから、
bitbakeの枠組みで問題回避するのは難しい印象なのと、静的なlinｋでの対応も、
こちらの環境では難しそうなところ理解できました。

とりあえず、対処療法的なやり方になってしまいますが、
レシピに以下のタスクを追加して対応することにしました(少々強引ですが・・・)
cp ${WORKDIR}/lua-${PV}/src/luac ${D}${bindir}/ } addtask luac_copyproc after do_install before do_populate_sysroot

相談に乗っていただきありがとうございました。
また何かありましたら、よろしくお願いいたします。