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

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

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

同じディス鳥であっても、ディス鳥のバージョンごとにバイナリが公開されているから
バイナリ互換は最低だね。
ソースを公開して、ある程度人気が出て、ディス鳥側に常にメンテしてもらわなければ
ソフトを作っても誰にも使われることがない。
個人でソフトを作って配布とかできないシステム。
決まりきったディス鳥認定ソフトしか使うことができないのさ。

ある程度人気出たら
「ディストリに入れよう」って人も出てくるけどなぁ。
入らなくても公式とは別にリポジトリ立てる人もいるし。

バイナリーの互換性がないから、Windowsにバカにされる。

動作しているライブラリやカーネルに
互換性が無い部分をｱﾌﾟﾘ側が場合分けして対応しているならともかく
それを行わないからandroidにもバカにされる。

バカにされても特に困らん。

気がついていないだけでソフトが少ないという点で困っていると思う。
ccでコンパイルしたa.outをVectorにアップロードしてもバイナリ互換がないので使える人がいない。
だから誰もプログラムを作らない。人気がない。ソフトがない。

ソースで上げればみんなコンパイルして使う。

Aという実装に依存してBという実装が作られるも
ある日突然Aが実装を変更して依存が壊れBという実装が動かなくなる

こういう場合
AかBのどちらかが問題を修正するなら問題無いけど
双方自分の実装が正しいと主張し修正を認めない時がある


こういうの何ていうの？

千日手

>>34
ユーザーがいちいちソースからコンパイルして使うというのはLinuxでは一般的ではないだろう。
面倒すぎて受け入れられていないということだ。
ソース配布してもコンパイルするには時間がかかって手間だし、もしやる気があっても知識不足から手をつけられない人も多いだろう。
自分が開発しもしないのに、多くの種類の開発環境をインストールするのもばかばかしいだろう。
ソースを公開したい人や会社も少ない。
少なくとも俺はソース公開したくない。
プログラマーにとってはソース公開なんて自殺行為だからな。
ソース互換も100%じゃないしな。
開発環境やカーネルやライブラリのバージョンなどの関係ですんなりコンパイルが通るとも限らない。
コンパイルでエラーが出たら多くの人はあきらめるだろう。
バイナリ互換があってソース公開の義務さえなければ、多くの会社や個人がプログラム作成に参戦するが
バイナリ互換などないし、場合によってはソース公開の義務が出ることもあり、みんなWindowsのプログラム作っているのが現状。

libc5のバイナリーがまだ残ってるマシンもってるけど、普通に動いてる。
さすがにa.out形式は残ってない。