glibc, DT_HASHの削除でユーザープログラムを書き直す必要に 11
ストーリー by nagazou
旧聞ではありますが 部門より
旧聞ではありますが 部門より
blueflow 曰く、
GNU Libc（glibc）にDT_HASHを含めるか,DT_GNU_HASHのみにするかはビルド時に選択できたが、おおくのdistroはDT_HASHを含めて出荷していた（IVYL'S BLOG）。
elfのシンボルハッシュを使うプログラム(libstrangle)などはDT_HASHに依存していた。DT_GNU_HASHのみになったのでそれを前提としていたプログラムから見ると、後方互換性がなくなったように見える(ただ、DT_HASHはABIの一部ではなかったので,glibcから見ると後方互換性の約束を一応守っている,ちなみに、glibcは前方互換性は保証してないので、リリースサイクルの遅いdistroだとバイナリが動かなかったりするよね)
少し前(8月くらい)にlinuxコミュニティで話題になっていたことだが、
まだsradで書かれてなかったのでかいてみる
ハイラムの法則 (スコア:3)
仕様として明記されてない挙動・実装でも，その利用者が十分に多ければその実装・挙動は正式な仕様に組み込まれるべき，という考え方があります．
いわゆるハイラムの法則です．
では DT_HASH はどうなのかというと，
- 8月以降ほとんど話題になってない．
- 動かなくなるのは商用ゲームで Easy Anti-Cheat（ゲームの不正防止モジュール）を組み込んでる製品などのごく一部のソフトだけ
- 大半のソフトウェアでは問題が起きない
- glibc のバグレポートも放置されている https://sourceware.org/bugzilla/show_bug.cgi?id=29456 [sourceware.org]
- ユーザープログラム側を DT_GNU_HASH に対応させるのはそんなに難しくない
- DT_HASHよりDT_GNU_HASHのほうが性能がよい
という状況です
つまり利用者が少ないのでハイラムの法則には当てはまらず，DT_HASHが復活することは無さそうです．
別解としては glibc 2.36 にパッチを当ててDT_HASH を再度実装するという方法もあります．再度実装といってもDT_HASHを削除したcommitをリバースパッチするだけの簡単な作業です．
ディストリビューションとしては当面はglibc側にパッチをあてて DT_HASH を提供，将来的には完全廃止という方針が無難な気がします．
DTのおにんにんを切り刻む (スコア:0)
http://www.sco.com/developers/gabi/latest/ch5.dynamic.html [sco.com]
Re: (スコア:0)
ぜんぜん詳しく無いけど、Linux用のバイナリはELFOSABI_GNUだからsysvのABIには縛られないって事なんだと思う。ELFOSABI_NONEならばDT_HASHは必須だけど。
Re: (スコア:0)
SCO なんて鼻つまみ者のサイトじゃなくて、別のがなかったのかよ。
Solarisのも [oracle.com] はどうだ、って Oracle かよ。
Re: (スコア:0)
クラッカー感涙モノの法則ですな
Re: (スコア:0)
「ユーザーが十分に多ければ約束されていないあらゆる挙動に依存される」という意味です。
つまり、インターフェイスがあるのに実装に依存するユーザーが多いという事実を説明するもので漏れのある抽象化の法則に繋がり、自明ではない抽象化云々の話です。
観測的にプライベートな実装などないとは言ってますが「仕様に組み込まれるべき」とは言ってません。
https://www.hyrumslaw.com/ [hyrumslaw.com]
うちの会社では (スコア:0)
未だにlibc5のプロプライエタリソフトウェアを動かすために悪いハックが口伝で伝わっている
Re: (スコア:0)
特定した
Re: (スコア:0)
「致命的にあたまがおかしい」は流石に言い方悪くない？あまり詳しくはない様だけど、興味があったからそれでも頑張ってタレ込んだんだろうし、「DT_HASHを含めて出荷していた」も今とは言ってないから過去のことを言いたかったのかもしれないし。
Re: (スコア:0)
NetBSD...