0

Buildroot(2017.02.5)を使用してカスタムクロスコンパイルツールチェーンを構築しています。私は2つのビルドルート構成を持っています。 1つはRFSを構築するツール、もう1つは純粋にツールチェーンを構築するツールです。意図的に再構築しない限り、ツールチェーンを再構築する必要がないため、この方法で構成されています。外部ツールチェーンとしてこのツールチェーンを参照するRFSを構築する構成です。Buildsを使用したBuildrootツールチェーン

一般に、構築されたツールチェーンは正常に動作しますが、私は#include<openssl/md5.h>という既存のアプリケーション(Linuxユーザースペース)をいくつか持っています。これをコンパイルしようとすると、"<openssl/md5.h>: No such file or directory"というエラーが発生します。これは、生成されたツールチェーンのsysrootディレクトリにopensslディレクトリが含まれていないためです。

ビルドルートにツールチェーン内のopensslを含めるにはどうすればよいですか?私が行ったすべての検索は、組み込み対象のopensslをクロスコンパイルすることを指しているようですが、これは問題ではありません。問題は、それをツールチェーンに含める必要があることです。

ターゲットパッケージ - >ライブラリ - > Crypto - > opensslがyに設定されていますが、このシナリオではRFS(およびdefconfig問題のRFSは作成されず、ツールチェーンのみが作成されます)。

OpenSSLをbuildrootツリーの外でコンパイルしてsysrootディレクトリにインストールすることはできますが、これはsysrootを汚染するので正しくないようです。

私はここに何か簡単なものがないと確信しています。

+0

ありがとうございます。カスタムソフトウェアのBuildrootの観点からパッケージを作成する必要があります。 – 0andriy

答えて

0

buildrootのドキュメントを読むと、Target packagesの下に選択されたパッケージが実際にはツールチェーンのsysrootにプッシュされていることが分かりました。これがうまくいかない理由は、make all(または単純なmake)とは対照的に、make toolchainを行っていたためです。パッケージは前者でビルドされていなかったので、ツールチェーンのsysrootには含まれていませんでした。

+0

Buildroot 2017.08では、make sdkを実行してすべてのパッケージをビルドし、その結果を再配置可能にすることもできます。しかし、rootfsで終わるopensslがSDKのものとまったく同じであることを確かめなければなりません。 – Arnout

関連する問題