2011-01-04 5 views
1

サードパーティのDLLに依存するCコードを含むR拡張を記述しています。コンパイルはR 2.11.0のRtoolsを使用してWindows上で行われています。私の計画は、DLLがソースパッケージと共に配布され、拡張のsrcディレクトリに格納されることです。私の質問は、サードパーティのDLLにリンクしようとすると、コンパイラにsrcディレクトリを調べさせる方法です。サードパーティ製DLLでR拡張をコンパイル

現在、私はコマンドでパッケージを構築しています:

R CMD build --binary MyPackage 

を私はまた、次の行をファイルのsrc/Makevarsを持っている:

PKG_LIBS = -ldlxapi32 

これは、サードパーティのDLLを保証します、dlxapi32.dllは、コンパイルに含まれています。しかし、私のパッケージのsrcディレクトリは標準ライブラリ検索パスの一部ではないので、コンパイラはDLLを見つけることができません。

PKG_LIBS = -L$(CURDIR) -ldlxapi32 

しかし、これは、次のような出力で失敗します:私は読むためにはsrc/Makevarsを変更することでこの問題を解決しようとしてい

ここ

gcc -shared -s -static-libgcc -o MyPackage.dll tmp.def dlx.o -L/cygdrive/c/DOCUME~1/abiel/LOCALS~1/Temp/Rbuild709236257/MyPackage/src -ldlxapi32 -Lc:/PROGRA~1/R/R-211~1.0/bin -lR 
c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe: cannot find -ldlxapi32 

、我々はその$(CURDIRを見ることができます)/cygdrive/c.DOCUME~1 /に評価されました。代わりに、srcディレクトリの実際の場所であるC:/ programming/r/MyPackage/srcと評価されることを期待していました。これを修正する方法はありますか?

答えて

2

あまりにも複雑な-L$(CURDIR)の代わりに、同等の-L.を使用してみませんか?

はまた、Rtoolsスイートは、これはまだCであるMinGWのように、私は/ cygdriveの/ C/...のようなパスを回避したいのCygwinされていないのMinGWを使用しています:/ ....

+0

おかげディルク、 - L.完璧に働いた。 – Abiel

+0

あなたはdllを別のディレクトリ、例えば/wlibs/so -L ../ wlibsに置いて、それが正しい 'installed'の場所$ R_LIBRARY_DIR/$ {R_PACKAGE_NAME}にコピーされるようにしたいと思う}/libs /。 R CMDチェックはsrc /のバイナリファイルについて文句を言うでしょう。 /cleanup.winはコピーを行う場所の1つです。ユーザーがPATHを指定すると、インストールされたdllが検出可能であることが重要です。 「R拡張の記述」のセクション1.2を参照してください。 –

+0

良い点。私はかつて似たようなことをしてパッケージ内のdllをinst/fileディレクトリ経由で出荷する(作業中の内部的な)パッケージを書きました。私は 'dyn.load()'にそれを期待する場所や何かを伝えなければならなかったと思います。それはすべて動作しますが、微調整が必​​要です。 –

関連する問題