アカウント名:
パスワード:
デバイスドライバのバイナリ互換性はどうかしらないけど、通常のプログラムのバイナリ互換性はかなり高い。もちろんちゃんと互換性を意識してないとダメだけど。10年前に作られた某社のバイナリの課金プログラムが CentOS 6.3 でもバッチリ動く。動作させるには互換ライブラリを入れる必要があった。
ABI は問題ないなくても、その上で動く動的リンクのライブラリ管理に問題があったりします。
これは kernel じゃなくてディストリビューションの問題と言うことなんだけど、同じライブラリの世代番号のまま中身が違ってたりするものだから、リンクエラーや動作の違いが生じたりする理由です。
バイナリを静的リンクすれば、そういう問題に影響されないのですが、こんどは図体がでかくなっちゃうしね。 いろいろなディストリビューションで動作する共通のバイナリを作るのはなかなか大変だった…と言う苦労をしたのはもう10年も前の話なのですが、今でもあまり変ってなさげですね。
動的リンクライブラリ(so/DLL、以後DLL)は「上手に使えば」凄く良いものですが上手に使うのが凄く難しい気がします…基本的にキライ完全に固まった(枯れた)ものを整理して使うには良いですが絶え間なく変わっていくものに使うとバージョン管理地獄か実は中身が非互換地獄か、DLL HELLが待っているわけで「完成するまでDLLにするな、DLLにしたら触るな」と言いたいのですが、そうするといつまでたってもDLLにできないとか
だから動いたところでアプリ~OSまでまるごとVMの上で動かせばいいのに…
で、VM の実行環境のほうではどうすんの?
わかった。アプリを起動したら開発者のマシンで実行されて結果が返ってくるというのはどうだ?
Windowsにすればいいじゃん。
プログラムに必要なライブラリも一緒のディレクトリに入れておけばいい。LD_LIBRARY_PATH=./ ./fooクローズドソースなプログラムは大抵これで済む。オープンソースならプロジェクトが生きている間なら自前でビルドできる。
下手に静的リンクしたり配布物に添付された.soを使われるとライブラリにバグやセキュリティホールが見つかったときに差し替えが難しい。
>LinuxにもWin Side-by-Sideみたいなのがあればいいのにね。
勘弁してくれ。あれはdll hellがmanifest hellになっただけだ。MSですらVS2010からCRTは昔のDLLに戻したというのに。
> LinuxにもWin Side-by-Sideみたいなのがあればいいのにね。> それともあるのかな?
相当する機能はLinux含むSunOS4系共有ライブラリを使うUNIX系OS一般にありますよ。
共有アセンブリに相当する機能は、共有ライブラリのSONAMEとして同一の名前を指定することにより行います。
プライベートアセンブリに相当する機能は、リンク時に -rpath オプションで、プライベートな共有ライブラリのパスを指定する(ないし、起動時のLD_LIBRARY_PATH環境変数を指定する)ことで行います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
linuxって意外とバイナリ互換性高い (スコア:0)
デバイスドライバのバイナリ互換性はどうかしらないけど、通常のプログラムのバイナリ互換性はかなり高い。もちろんちゃんと互換性を意識してないとダメだけど。
10年前に作られた某社のバイナリの課金プログラムが CentOS 6.3 でもバッチリ動く。動作させるには互換ライブラリを入れる必要があった。
Re:linuxって意外とバイナリ互換性高い (スコア:1)
ABI は問題ないなくても、その上で動く動的リンクのライブラリ管理に問題があったりします。
これは kernel じゃなくてディストリビューションの問題と言うことなんだけど、同じライブラリの世代番号のまま中身が違ってたりするものだから、リンクエラーや動作の違いが生じたりする理由です。
バイナリを静的リンクすれば、そういう問題に影響されないのですが、こんどは図体がでかくなっちゃうしね。 いろいろなディストリビューションで動作する共通のバイナリを作るのはなかなか大変だった…と言う苦労をしたのはもう10年も前の話なのですが、今でもあまり変ってなさげですね。
の
Re:linuxって意外とバイナリ互換性高い (スコア:1)
動的リンクライブラリ(so/DLL、以後DLL)は「上手に使えば」凄く良いものですが上手に使うのが凄く難しい気がします…基本的にキライ
完全に固まった(枯れた)ものを整理して使うには良いですが絶え間なく変わっていくものに使うとバージョン管理地獄か実は中身が非互換地獄か、DLL HELLが待っているわけで
「完成するまでDLLにするな、DLLにしたら触るな」と言いたいのですが、そうするといつまでたってもDLLにできないとか
Re:linuxって意外とバイナリ互換性高い (スコア:2)
だから動いたところでアプリ~OSまでまるごとVMの上で動かせばいいのに…
Re:linuxって意外とバイナリ互換性高い (スコア:2)
で、VM の実行環境のほうではどうすんの?
Re: (スコア:0)
わかった。
アプリを起動したら開発者のマシンで実行されて結果が返ってくるというのはどうだ?
Re: (スコア:0)
Windowsにすればいいじゃん。
Re:linuxって意外とバイナリ互換性高い (スコア:1)
Re: (スコア:0)
プログラムに必要なライブラリも一緒のディレクトリに入れておけばいい。
LD_LIBRARY_PATH=./ ./foo
クローズドソースなプログラムは大抵これで済む。オープンソースならプロジェクトが生きている間なら自前でビルドできる。
Re: (スコア:0)
下手に静的リンクしたり配布物に添付された.soを使われるとライブラリにバグやセキュリティホールが見つかったときに差し替えが難しい。
Re: (スコア:0)
それともあるのかな?
まぁ、Windowsらしくわかりづらいし、あまり美しくはない解決策ではあるけれども。
Re:linuxって意外とバイナリ互換性高い (スコア:2)
Re: (スコア:0)
>LinuxにもWin Side-by-Sideみたいなのがあればいいのにね。
勘弁してくれ。あれはdll hellがmanifest hellになっただけだ。MSですらVS2010からCRTは昔のDLLに戻したというのに。
Re: (スコア:0)
> LinuxにもWin Side-by-Sideみたいなのがあればいいのにね。
> それともあるのかな?
相当する機能はLinux含むSunOS4系共有ライブラリを使うUNIX系OS一般にありますよ。
共有アセンブリに相当する機能は、共有ライブラリのSONAMEとして同一の名前を指定することにより行います。
プライベートアセンブリに相当する機能は、リンク時に -rpath オプションで、プライベートな共有ライブラリのパスを指定する(ないし、起動時のLD_LIBRARY_PATH環境変数を指定する)ことで行います。