glibc 2.1.3では、ユーザーがe2fsck（8）コンパイルエラーが原因でデータ損失が発生したと文句を言うときに、リンクタイム警告を追加します。
「この
llseek機能は危険です。代わりに `lseek64を使用してください。」これにより、警告のないコンパイルが必要な場合、関数は使用できなくなります。
glibc 2.28以降、この関数シンボルは新しくリンクされたアプリケーションでは使用できなくなりました。
この背後に隠された物語は何ですか？
ベストアンサー1
問題は、glibcのllseekヘッダファイルに対応する宣言のないシンボルが含まれていることです。e2fsck構成スクリプトはこのシンボルを検出し、これが機能を使用できることを意味すると仮定します。ただし、暗黙的な関数宣言が関数が期待するものと一致しないため、関数呼び出しが誤ってコンパイルされる可能性があります。特にllseek64ビットオフセットが必要ですが、暗黙の宣言によってintパラメータが生成されます。これにより、e2fsck予想とは異なるオフセットで変更が行われるため、データ損失が発生します。
e2fsckこれを使用する理由は、llseeklibc5（Linuxのglibcの前身）がそれを宣言して使用可能にするからです（位置unistd.h）。したがって、e2fscklibc5用にビルドすると正しく機能しますllseekが、glibc用にビルドするとビルドは成功しますが機能しません。
この問題はe2fsprogs 1.12で修正され、変更ログエントリは次のとおりです。
E2fsprogsはglibcで動作します（少なくともRedHat 5.0に付属のバージョンでは）。 llseek（）が存在しなくても、ext2fs_llseek（）関数はi386 ELF共有ライブラリで機能します。また、(a) llseek が libc にあること、(b) llseek がシステムヘッダファイルで宣言されていることを確認するために、明示的な設定テストを実行します. （libc開発者が以前のバージョンのlibcとの互換性の概念を理解していないという標準的な苦情を参照してください。）
llseekコードが;を使用しようとしたときに警告するようにCライブラリも変更されました。ディスカッションはメーリングリストのアーカイブにあります。。