0

NDK スタンドアロン ツールチェーンとバイオニックのいくつかの制限に基づいて、次の一般的な設定で crosstool-NG を使用して独自のツールチェーンを作成しました。

  • binutils-2.22
  • gfortran を有効にした gcc-4.5.3
  • glibc-2.14.1
  • カーネルヘッダー-2.35.7
  • アーチアーム4t

これを使用して、実行可能ファイルをビルドし、libc、ld-linux などを含むすべての依存関係を Android デバイスにアップロードします。ld-linux.so.3 --library-path ... を使用して実行可能ファイルを手動で実行します。

これは非常に複雑な実行可能ファイルであり、system("pwd") や system(NULL) などの基本的なものであっても、system() 呼び出しを実行すると、ステータスとして 127 が返される (見つかりません) . さらに進んで、代わりに popen を使用して応答を収集すると、次のようになります。

* glibc が検出された *二重解放または破損

何が起こっている？誰かが同様のことで成功しましたか? 権限の問題はありますか? system() 呼び出しを不可能にする Android の根本的な違いはありますか? Bionic が system と popen (ソース コード) を最終的にどのように処理するかはどこで確認できますか? NDK を使用すると system() 呼び出しを実行できると思います。

4

2 に答える 2

1

(1) SHELLAndroid では環境変数が設定されていない可能性があります。デフォルトのシェル/bin/shは存在しません（AFAIK）。にあり/system/bin/shます。これがおそらくsystem失敗の原因です。

(2) GitHub で実装を見つけることができます: system、popen。glibc でのクラッシュは、ライブラリのバグのように思えます (popenシグナル ハンドラまたはマルチスレッド環境で使用している場合を除きます) 。

于 2012-09-09T06:21:42.270 に答える
1

の独自のバージョンを展開することをお勧めしますsystem。まったく複雑ではなく、失敗した正確なシステム コールと失敗したエラーを特定できます。ほとんどの場合、シェルが正しくなく、それがエラーの原因です。ライブラリが存在しないシェル プログラムを指定しています。

于 2012-09-09T06:18:01.463 に答える