Linuxって実際の所バイナリ互換どれくらいあるの？

原則としてディストリやバージョンが変われば
再コンパイルする必要があるってのはわかる。

でも実は再コンパイルしなくても動いたりするんじゃないか？
世の中にはソースを公開できないアプリがある。

そういうアプリを作っている会社がいちいち各ディストリや
各バージョンに対応するのは手間がかかる。
結果、自分のディストリ・バージョンに正式対応していないが
実は結構動くんじゃないかって疑問になった。

原則として動くんじゃないの
firefoxとかどこでも動くじゃん

時間の経過でglibcとかlibstdc++のABIや定義シンボルが変わって
動かなくなったことはあった。あとは使ってる共有ライブラリ名の
参照名が違っててロードできないとか。

だからバイナリ互換性にこだわるならstatic linkするしかない。
最近だと良くなってる気はするので、「いまどき」の環境で「いま」
リリースするバイナリが概ね動けばいいだけならおおよそ動くと思うけど。

どっちかと言うとファイルの置き場所とか

VMwareみたいにlibX*を同梱する強者もいるよな。
そこまでするなら仮想マシンイメージで配布…無理か。

>>5
仮想イメージでってのは単体のアプリではあまり聞かないけど、アプライアンス方面では
増えてきてるよ。インストール調整費用が価格と稼動までの日数を押し上げてて
競争力の低下要因となっているからね。

>>6
アプライアンスなのに。

>>7
アプライアンスは別に専用設計のH/Wって訳じゃないから。
特に適用業務ごとにスケールが大きく異なる場合、ベースは汎用のPCを
使うことはよくある。

>>8
アプライアンスなんだからH/W決め打ち出来るじゃん。

VMに決め打ちしてるんだよ。

Ubuntuも結局はDebianとのバイナリ互換性が維持され続けてるな

よっぽどコアな部分叩いてるんでもなければ普通にバイナリ互換だろ

>>12
ppc向けのバイナリ

普通って言うほど安心はできない。
ビルド環境のライブラリとバージョンが違ってトラブルとかあるし。

バイナリ互換があれば、どのディストリ、どのバージョンでも
アプリが使えるから、アプリのポータブル化して
あちこちに設定ファイルごとアプリもっていけるのにね。

もうそのあたりは仮想化におまかせで、/ 以下をまるごとパッキングに
なるのかなー。

それをLXCとかの下でカーネルだけ共通で動かすもよし、KVMで
カーネルから分離して動かすもよし。

>>15
実際にはもっと色々障壁なくね？

まーでも実際問題市販アプリケーションってバイナリで出てくるからね

>>17
kernelやglibcに限らず、依存してるさまざまなライブラリなんかのバージョンとかな。

system callはあまり変わっていないんだっけ？POSIX互換に限らず…

システムコールはむしろLinuxがPOSIX非準拠だったのを細々と直してる。
でもそんな細部に依存してるアプリはまずないだろう。

glibcが怖いんだな。

パッケージマネージャでNixが普及してくれればバイナリ互換性とかライブラリ互換性気にしなくて良くなりそうだけどどうなんだろ

使っているglibcの--enable-kernelオプションが
違うだけでもバイナリ互換性が無くなる。

例えば最近のFedoraのglibcは--enable-kernel=2.6.32で
コンパイルされているので、このglibcは勿論、この
glibcを使ってコンパイルされたバイナリもkernel 2.6.32未満では
動かない。

$ file /bin/ls
/bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs),
for GNU/Linux 2.6.32, <======
BuildID[sha1]=0xaad547afe804114c881db3ca6e337794431b93f4, stripped

（RHEL 5.xのバイナリはRHEL 6.xで動く可能性が
あるが、RHEL 6.xのバイナリはRHEL 5.xでは動かない）

てs

>>25
test
http://engawa.2ch.net/test/read.cgi/linux/1341351394/

test

漢なら潔く拡張命令モリモリ利用

バイナリ互換性なんて気にしないぜ！