MailPeeper_menu.appのGmail対応 - OpneSSLライブラリをXcodeから使う１ [プログラミング]
検証コードでは、gccの引数いかんで、ライブラリの関数を取り入れる事ができました。Xcodeなプロジェクトではまだやってないので、XcodeでC言語のライブラリを使いたいと思います。できれば、外部のライブラリが要らないようにしたい。というか、別途ライブラリ導入ってダメでしょ。だから.appに内包したいのです。
参考になりそうなのは以下のリンク。どっちも画面キャプチャがあってわかりやすい。自分はここまでの事はしたくないな。やれる、という事実を伝えます。
http://cocoadays.blogspot.com/2010/11/ios-static-library-1.html
http://www.macmacmac.mydns.jp/modules/tinyd0/index.php?id=11
どっちもXcodeで作ったライブラリを、Xcodeで使うというもので、OpenSSLライブラリをXcodeに適合させるのはしんどそう。「./configure && make && sudo make install」なライブラリを、Xcodeでコンパイルってあんまり生産的な作業じゃない気がするのね。
どうにか普通にgccから吐き出される.aなスタティックライブラリか、.dylibなダイナミックライブラリを導入させる事はできないのだろうか。誰かやってないかなー。
これとか良さげだなぁ。
http://www.geocities.jp/parastyx/CUDA/
うぁやっぱ、内部でライブラリを持ってっていう形になってない。まんま、C言語で作ったライブラリのパスをリンクしてあげているだけだ。このくらいの事なら設定でできそうなのはわかっている。だって、まんまgccでやった検証コードの設定を反映してあげれば良いだけの話だろうから。
んー有用な情報がないな。自分で試行錯誤するしかないのかな…。
やっぱりOpenSSLをgccとかで作ったのって、Xcodeで使えないのかな。色々ググっているけど、どうにも的を射ていないのだが、絞りすぎて英語サイトばっかり引っかかってくる。特に気にせず、適当にlibssl.dylibを入れてコンパイルして、詳しくビルド結果を見てみた（それまでキチンと見とらんかった）。
ld: warning: in なんとかかんとか/libssl.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
って書いてあるから、ユニバーサルバイナリにi386用のバイナリが必要らしい。確かにコンパイルするときは、x86_64でコンパイルした覚えがある。MacPortsでopensslを入れたときも、多分、x86_64でコンパイルしてるんじゃないか、と思われ。
を、やっぱりMacPortsではi386のは入ってないみたい。ここでちょっと考える。mailpeeper_menu.appを64bit化をすれば良いのでは、という考えと、gccの引数を変えたりして、libssl.dylib側をユニバーサルバイナリで32bit対応する、ということ。
file もにょもにょ/MailPeeper_Menu.app/Contents/MacOS/MailPeeper_Menu
もにょもにょ/MailPeeper_Menu.app/Contents/MacOS/MailPeeper_Menu: Mach-O executable i386
確かにコンパイルされてるのは、i386用にしかコンパイルされてない。つーか、fileっていうコマンドすげーな、名前が。だってファイルだよ。名前つけた人間の意図がわからん。今までUniversal Binaryなんて特に気にもしてなかったんだけど、直接こういう状態に陥ると真剣に調べざるを得ない。ええと、XcodeでCocoaのユニバーサルバイナリってどうなってるんだ。
プロジェクトの設定で、アーキテクチャ（ARCHS）を32bit Universalから、Standard(32/64-bit universal)にして、クリーンしてコンパイルし直し。なんでXcodeにはVisual Studioみたいに、リビルドがないんだろうか。気を使っていちいち単独でクリーン、ビルドとかしたくないんだけど。それにクリーンする時にいちいちダイアログが出るのもうざい。
結果は、結局、変わらず。アクティブアーキテクチャをx86_64にしても、どうにもi386の部分で引っかかってリンクが通らない。こうなったら無理矢理、通したくなってきた。プロジェクト設定のアーキテクチャを64bit-Intelにしてみたら、ザラザラと出ていたリンクのエラーがほとんど消えた。SSH_read()だけ残ってるのが気になるが、リンクはコレでいけそう。
でも、お作法としては、.appも.dylibも、どっちもユニバーサルバイナリで、32bit(x386)と64bit(x86_64)を両対応にした方がいい。でも、面倒くさいな。特にMakefileなりconfigureなりを改変しなくてはならないopensslをコンパイルし直すのは面倒。それは、そのうちすることにして、無視して先に進みたい。
先のSSL_read()が見えないという問題はわけが分からない。リンクが通らないと当然バイナリができないので厳しい。まず、OpenSSLのヘッダファイル、ssl.hには書いてある。もちろん、libssl.dylibにも入ってる。下記のコードで確かめ済み。
nm libssl.dylib | grep SSL_read
呼んでいるSSL_read()をコメントアウトして、ビルドすると最後までリンクが通った。なぜゆえ、SSL_readのみ問題なん？ あ、SSL_read()が、SSH_read()になっとる…。うわ、恥ずかしいTYPOミスや。このくらい短い関数名だと手で打ち込んじゃうのもあって、ミスを見逃していた。それにSSLとSSHって意味的にも似てるし…。疲れたので続きは後日。
参考になりそうなのは以下のリンク。どっちも画面キャプチャがあってわかりやすい。自分はここまでの事はしたくないな。やれる、という事実を伝えます。
http://cocoadays.blogspot.com/2010/11/ios-static-library-1.html
http://www.macmacmac.mydns.jp/modules/tinyd0/index.php?id=11
どっちもXcodeで作ったライブラリを、Xcodeで使うというもので、OpenSSLライブラリをXcodeに適合させるのはしんどそう。「./configure && make && sudo make install」なライブラリを、Xcodeでコンパイルってあんまり生産的な作業じゃない気がするのね。
どうにか普通にgccから吐き出される.aなスタティックライブラリか、.dylibなダイナミックライブラリを導入させる事はできないのだろうか。誰かやってないかなー。
これとか良さげだなぁ。
http://www.geocities.jp/parastyx/CUDA/
うぁやっぱ、内部でライブラリを持ってっていう形になってない。まんま、C言語で作ったライブラリのパスをリンクしてあげているだけだ。このくらいの事なら設定でできそうなのはわかっている。だって、まんまgccでやった検証コードの設定を反映してあげれば良いだけの話だろうから。
んー有用な情報がないな。自分で試行錯誤するしかないのかな…。
やっぱりOpenSSLをgccとかで作ったのって、Xcodeで使えないのかな。色々ググっているけど、どうにも的を射ていないのだが、絞りすぎて英語サイトばっかり引っかかってくる。特に気にせず、適当にlibssl.dylibを入れてコンパイルして、詳しくビルド結果を見てみた（それまでキチンと見とらんかった）。
ld: warning: in なんとかかんとか/libssl.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
って書いてあるから、ユニバーサルバイナリにi386用のバイナリが必要らしい。確かにコンパイルするときは、x86_64でコンパイルした覚えがある。MacPortsでopensslを入れたときも、多分、x86_64でコンパイルしてるんじゃないか、と思われ。
file /opt/local/lib/libssl.1.0.0.dylib /opt/local/lib/libssl.1.0.0.dylib: Mach-O 64-bit dynamically linked shared library x86_64
を、やっぱりMacPortsではi386のは入ってないみたい。ここでちょっと考える。mailpeeper_menu.appを64bit化をすれば良いのでは、という考えと、gccの引数を変えたりして、libssl.dylib側をユニバーサルバイナリで32bit対応する、ということ。
file もにょもにょ/MailPeeper_Menu.app/Contents/MacOS/MailPeeper_Menu
もにょもにょ/MailPeeper_Menu.app/Contents/MacOS/MailPeeper_Menu: Mach-O executable i386
確かにコンパイルされてるのは、i386用にしかコンパイルされてない。つーか、fileっていうコマンドすげーな、名前が。だってファイルだよ。名前つけた人間の意図がわからん。今までUniversal Binaryなんて特に気にもしてなかったんだけど、直接こういう状態に陥ると真剣に調べざるを得ない。ええと、XcodeでCocoaのユニバーサルバイナリってどうなってるんだ。
プロジェクトの設定で、アーキテクチャ（ARCHS）を32bit Universalから、Standard(32/64-bit universal)にして、クリーンしてコンパイルし直し。なんでXcodeにはVisual Studioみたいに、リビルドがないんだろうか。気を使っていちいち単独でクリーン、ビルドとかしたくないんだけど。それにクリーンする時にいちいちダイアログが出るのもうざい。
結果は、結局、変わらず。アクティブアーキテクチャをx86_64にしても、どうにもi386の部分で引っかかってリンクが通らない。こうなったら無理矢理、通したくなってきた。プロジェクト設定のアーキテクチャを64bit-Intelにしてみたら、ザラザラと出ていたリンクのエラーがほとんど消えた。SSH_read()だけ残ってるのが気になるが、リンクはコレでいけそう。
でも、お作法としては、.appも.dylibも、どっちもユニバーサルバイナリで、32bit(x386)と64bit(x86_64)を両対応にした方がいい。でも、面倒くさいな。特にMakefileなりconfigureなりを改変しなくてはならないopensslをコンパイルし直すのは面倒。それは、そのうちすることにして、無視して先に進みたい。
先のSSL_read()が見えないという問題はわけが分からない。リンクが通らないと当然バイナリができないので厳しい。まず、OpenSSLのヘッダファイル、ssl.hには書いてある。もちろん、libssl.dylibにも入ってる。下記のコードで確かめ済み。
nm libssl.dylib | grep SSL_read
呼んでいるSSL_read()をコメントアウトして、ビルドすると最後までリンクが通った。なぜゆえ、SSL_readのみ問題なん？ あ、SSL_read()が、SSH_read()になっとる…。うわ、恥ずかしいTYPOミスや。このくらい短い関数名だと手で打ち込んじゃうのもあって、ミスを見逃していた。それにSSLとSSHって意味的にも似てるし…。疲れたので続きは後日。
タグ：freesoft
コメント 0