結果のRPMでのアーキテクチャの制御

x86_64環境にこれらのRPMをインストールできるようにするため、自分のターゲットアーキテクチャ向けに作成したすべてのレシピを自分のホストシステムアーキテクチャ（x86_64）用に構築しようとしています。結果のRPMでのアーキテクチャの制御

これを行うには、単にMACHINE=genericx86-64を設定してビルドします。しかし、結果として得られるRPMのアーキテクチャはcore2_64に設定されているようです。私はbitbakeを実行しているときに報告されているTUNE_FEATURES="m64 core2"に関連していると思います（下記参照）。

私のホスト（RHEL7）がそれらを受け入れるために、これらのRPMがx86_64として終了するようにするにはどうすればよいですか？

Build Configuration: 
BB_VERSION  = "1.34.0" 
BUILD_SYS   = "x86_64-linux" 
NATIVELSBSTRING = "universal-4.8" 
TARGET_SYS  = "x86_64-poky-linux" 
MACHINE   = "genericx86-64" 
DISTRO   = "generic-panel" 
DISTRO_VERSION = "0.7" 
TUNE_FEATURES  = "m64 core2" 
TARGET_FPU  = ""

例

# rpm -i xxx.core2_64.rpm 
package xxx.core2_64 is intended for a different architecture 

$ uname -a 
Linux localhost 3.10.0-693.2.2.el7.x86_64 #1 SMP Sat Sep 9 03:55:24 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux

出典

2017-10-17 aerkenemesis

これを行わないことをおすすめできますか？ RPMは、rpmを受け入れるものにアーチを作ったとしても、RHEL（またはYoctoを使って作成しているディストリビューション以外のディストリビューション）との互換性や安全性が保証されていません。 – jku

@jkuヘッドアップに感謝します。 RHELで使用するのが不適切な理由は何ですか？また、代替案の提案はありますか？ – aerkenemesis

まあ、私は間違いなく動作しないとは言いませんが、パッケージはOSや他のパッケージについての前提をしています。 YoctoとRHELで使用されるパッケージ名であっても、パッケージの機能はもちろんのこと、名前が異なるためRHEL上に見つからないパッケージに依存する可能性があります。これは、同じパッケージ形式を使用する2つの異なるオペレーティングシステムの問題です。 – jku

ソリューションはDEFAULTTUNE変数を変更することでしたので、私はちょうど私のlocal.confにDEFAULTTUNE_genericx86-64 = "x86-64"を追加しました。

出典

2017-10-17 14:57:06 aerkenemesis

結果のRPMでのアーキテクチャの制御

答えて

関連する問題