背景
OSXで問題なく、ビルド出来てるlibtrusterd、ボスがつけてる
バッチをつけようと、まえまえ、から断片的に知っていたtravis ciを
さくっと使い、近代的なgithubの使い方が出来てない俺でも、ボスを
あっと言わせてやろと考えた。
Linuxでビルドするには茨の道
いろいろあったので、後で小出し予定ｗ
何でclang
trusterdがclang使ってる。
libhoge.aをフルパスで指定するとNG
clang -shared ore.c -o libtrusterd.so mruby/foo/bar/libhoge.a -Lmruby/lib -lsugoi
他の.soライブラリもlibtrusterd.soを作成する際に指定しているが、
これらは問題無く、どうやら、libhoge.aの中のシンボルだけが
NG(nmコマンドの見方がイマイチ分からず、
ほんとに、libhoge.aだけかは確証をもって作業を指定なかったけど)
h2oで知ったとっておきの技を試す
ar コマンドでlibhoge.aをバラし、オブジェクトファイルにする。
ar x mruby/foo/bar/libhoge.a
これで、
clang -shared ore.c -o libtrusterd.so *.o -Lmruby/lib -lsugoi
のような感じで無事に実行してもシンボル参照エラーとならないlibtrusterd.soが
出来た。
ふとGoのとある記事のことを思い出す。
この記事の中で、libhoge.aを-lhogeでもリンク出来ていた事を思い出した。
やってみた。
clang -shared ore.c -o libtrusterd.so -Lmruby/foo/bar/ -lhoge -Lmruby/lib -lsugoi
まとめ
共有ライブラリを作る際の知識がまだまだ不足して、
理屈が分からず、試行錯誤で解決している。
まぁ、動くのが大事だけど、理屈もそのうち。
ただ、なんとく、フルパス指定だと、リンカに直接.aファイルを渡すことに成り、
とあるサイトでは、リンカは.so作成時に.aはリンク出来ない旨を見つけたから、
これが事実なら、今回の動きは納得できる。
あ、OSXではこれができてるんだよなぁ。。