アカウント名:
パスワード:
WindowsだとQtとかwxWindowsとかboostみたいな巨大ライブラリはDLLだとパスが関係してきたりするし、静的リンクにするにはサイズが大きかったりと扱いづらいと感じます。
特に、最近は64bitプラットフォームが一般化してきて32bitだけ入れとけばいいと言う訳にはいかなくなってきたので、適切なプラットフォーム用のDLLを読ませるためにアプリと同じディレクトリに入れたりすると共有ライブラリの意味が薄らいでしまうし、DLL名の衝突を避けられる置き場所が限定されるので共有ライブラリ化には疑問を持っているのですが、ビルド済みのライブラリの配布はDLLになっていることが多いですね(DLLを使用する設定がデフォルトだったり静的リンクにするとCのランタイムも静的リンクになってしまうとか)。
フレームワークにも新機能を追加していくから、一度組み込まれた物は簡単に外すことができなくてさらに巨大化してしまうというのもあります。
いや、それはgccにまつわる問題でしょ。VisualC++Express使ってるとサイズが一桁縮みますwいまだにファイル名がc:\users\myname じゃなくて /c/users/myname/だったりするし なんというかAPI使わずに再実装している部分がでかいのかなぁ。
5年以上前にwxとMingWの組み合わせでGUI版ハローワールドで10MB超えたなあw
DLLでなく、静的リンクにしたから、とか言うオチじゃないよね?
いや、静的だろうが動的だろうが、最終的に単体配布するなら結局そのサイズ分のインストールになるからDLLなら単体は小さいなんて事は重要ではない
それは、コンパイラにgccを使うか、Visual C++ Expressを使うかで変わる問題か?wxはよく知らないけど、wx+gccの組み合わせと、wx+Visual C++ Expressの組み合わせで配布する容量はそんなに違うの?
うん ひとけた違う理由は謎
うん ひとけた違う
MinGW環境のつもりが、Cygwin環境だったとかじゃない?
一桁って、絶対値ではいくらくらいよ?
理由は謎
リンクしているライブラリが違うのか、リンク前のオブジェクトファイルのサイズが違うのか、くらいは判るだろ?*.exeがリンクしているDLLは、Cygwin環境があれば
objdump -p 《*.exeファイル名》
で調べることができるぞ。
あと、まさかとは思うけど、デバッグオプションの違いとかじゃないよな?
何年も前にVCExpressに移行しちゃったし、Win32++というフレームワークに乗り換えからテスト環境も何にも無い。もうwxを使えるカラダじゃないw
ただ、gcc+wxのバイナリをダウンロードすれば今でもサイズが大きいのがゴロゴロしている。VCで1MB超えるexeってあんまりないけどgcc+wxなら10MBクラスがざらにある。
もうwxを使えるカラダじゃないw
使う必要のない方法を書いたつもりだけど、解らなかった?
なんてーのかなー。それはコンパイラのせいじゃないと思うなあ。いくらなんでも、コンパイラの差だけで、10倍以上もサイズに差が出るとは思えない。やっぱり、あるとすれば、リンクしているライブラリの差じゃない?そうでないとすれば、コンパイラオプションが違いするぎるとか。
VCで自前ビルドしたRuby1.9のbinの下が1.2MB(これでstatic link)usbrumix2のzipのbinの下が9MB
公平な条件じゃないけどね、今も一桁違う予感。
VCで自前ビルドしたRuby1.9のbinの下が1.2MB(これでstatic link)
ふーん。ちなみに、CentOSのRubyは、
$ ls -lh $(which ruby)-rwxr-xr-x 1 root root 5.8K Mar 8 2013 /usr/bin/ruby$
だけどな。もちろんこれは、gccでコンパイルされている。何が動的にリンクされているかと言うと、
$ ldd $(which ruby) linux-gate.so.1 => (0x0035d000) libruby.so.1.8 => /usr/lib/libruby.so.1.8 (0x00658000) libpthread.so.0 => /lib/i686/nosegneg/libpthread.so.0 (0x0063c000) libdl.so.2 => /lib/libdl.so.2 (0x00620000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x047bc000) libm.so.6 => /lib/i686/nosegneg/libm.so.6 (0x005f5000) libc.so.6 => /lib/i686/nosegneg/libc.so.6 (0x00493000) /lib/ld-linux.so.2 (0x00474000)$
とまあ、予感ばかりに頼ってないで、こういう風に調べてみたらどうなる? 意外な結果が出るかもよ。
staticリンクのMSVC版RubyをdependsというツールでDLLを追跡するとmsvcr100-ruby191.dll(1.2MB)KERNEL32,USER32,ADVAPI32,SHELL32,WS2_32,IMAGEHELP,MSVCR100これだけ。
usbrumix2だとmsvcrt-ruby200.dll(2.2MB)上記にSHELL32,SHLWAPIが加わり、MSVR100がMSVCRTに変わる。
DLL関係が違うだけなのに、倍のサイズ取ってるね。
より正確には、1.8倍強だね。その程度なら十分考えられる範囲。
で結局、「一桁違う予感」とやらは当たってなかったね。# その一桁が二進数なら当たってるけどさ(笑)。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
巨大なフレームワーク (スコア:0)
WindowsだとQtとかwxWindowsとかboostみたいな巨大ライブラリはDLLだとパスが関係してきたりするし、
静的リンクにするにはサイズが大きかったりと扱いづらいと感じます。
特に、最近は64bitプラットフォームが一般化してきて32bitだけ入れとけばいいと言う訳にはいかなくなってきたので、
適切なプラットフォーム用のDLLを読ませるためにアプリと同じディレクトリに入れたりすると共有ライブラリの意味が薄らいでしまうし、
DLL名の衝突を避けられる置き場所が限定されるので共有ライブラリ化には疑問を持っているのですが、
ビルド済みのライブラリの配布はDLLになっていることが多いですね
(DLLを使用する設定がデフォルトだったり静的リンクにするとCのランタイムも静的リンクになってしまうとか)。
フレームワークにも新機能を追加していくから、一度組み込まれた物は簡単に外すことができなくてさらに巨大化してしまうというのもあります。
Re: (スコア:0)
いや、それはgccにまつわる問題でしょ。
VisualC++Express使ってるとサイズが一桁縮みますw
いまだにファイル名が
c:\users\myname じゃなくて /c/users/myname/だったりするし
なんというかAPI使わずに再実装している部分がでかいのかなぁ。
5年以上前にwxとMingWの組み合わせで
GUI版ハローワールドで10MB超えたなあw
Re: (スコア:1)
5年以上前にwxとMingWの組み合わせで
GUI版ハローワールドで10MB超えたなあw
DLLでなく、静的リンクにしたから、とか言うオチじゃないよね?
Re: (スコア:0)
いや、静的だろうが動的だろうが、
最終的に単体配布するなら結局そのサイズ分のインストールになるから
DLLなら単体は小さいなんて事は重要ではない
Re: (スコア:1)
いや、静的だろうが動的だろうが、
最終的に単体配布するなら結局そのサイズ分のインストールになるから
DLLなら単体は小さいなんて事は重要ではない
それは、コンパイラにgccを使うか、Visual C++ Expressを使うかで変わる問題か?
wxはよく知らないけど、wx+gccの組み合わせと、wx+Visual C++ Expressの組み合わせで配布する容量はそんなに違うの?
Re: (スコア:0)
うん ひとけた違う
理由は謎
Re: (スコア:1)
うん ひとけた違う
MinGW環境のつもりが、Cygwin環境だったとかじゃない?
一桁って、絶対値ではいくらくらいよ?
理由は謎
リンクしているライブラリが違うのか、リンク前のオブジェクトファイルのサイズが違うのか、くらいは判るだろ?
*.exeがリンクしているDLLは、Cygwin環境があれば
で調べることができるぞ。
あと、まさかとは思うけど、デバッグオプションの違いとかじゃないよな?
Re: (スコア:0)
何年も前にVCExpressに移行しちゃったし、
Win32++というフレームワークに乗り換えから
テスト環境も何にも無い。
もうwxを使えるカラダじゃないw
ただ、gcc+wxのバイナリをダウンロードすれば
今でもサイズが大きいのがゴロゴロしている。
VCで1MB超えるexeってあんまりないけど
gcc+wxなら10MBクラスがざらにある。
Re: (スコア:1)
もうwxを使えるカラダじゃないw
使う必要のない方法を書いたつもりだけど、解らなかった?
なんてーのかなー。それはコンパイラのせいじゃないと思うなあ。
いくらなんでも、コンパイラの差だけで、10倍以上もサイズに差が出るとは思えない。
やっぱり、あるとすれば、リンクしているライブラリの差じゃない?
そうでないとすれば、コンパイラオプションが違いするぎるとか。
Re: (スコア:0)
VCで自前ビルドしたRuby1.9のbinの下が1.2MB(これでstatic link)
usbrumix2のzipのbinの下が9MB
公平な条件じゃないけどね、今も一桁違う予感。
Re:巨大なフレームワーク (スコア:1)
VCで自前ビルドしたRuby1.9のbinの下が1.2MB(これでstatic link)
ふーん。
ちなみに、CentOSのRubyは、
だけどな。もちろんこれは、gccでコンパイルされている。
何が動的にリンクされているかと言うと、
とまあ、予感ばかりに頼ってないで、こういう風に調べてみたらどうなる? 意外な結果が出るかもよ。
Re: (スコア:0)
staticリンクのMSVC版RubyをdependsというツールでDLLを追跡すると
msvcr100-ruby191.dll(1.2MB)
KERNEL32,USER32,ADVAPI32,SHELL32,WS2_32,IMAGEHELP,MSVCR100
これだけ。
usbrumix2だと
msvcrt-ruby200.dll(2.2MB)
上記にSHELL32,SHLWAPIが加わり、
MSVR100がMSVCRTに変わる。
DLL関係が違うだけなのに、倍のサイズ取ってるね。
Re:巨大なフレームワーク (スコア:1)
DLL関係が違うだけなのに、倍のサイズ取ってるね。
より正確には、1.8倍強だね。その程度なら十分考えられる範囲。
で結局、「一桁違う予感」とやらは当たってなかったね。
# その一桁が二進数なら当たってるけどさ(笑)。