2017-12-16 41 views
2

アプリケーションmyapp.exeg++を使用して構築され、libstdc++.soなしの環境にインストールできるように、フラグ-static-libstdc++を使用するとします。 myapp.exeは、シャードライブラリからdlopen経由で動的にロードできる一部の機能plugfのプラグインサポートを追加しています。標準ライブラリで静的にリンクするときの動的プラグインのサポート方法

libplug.solibstdc++にリンクしているようなプラグインライブラリの場合は、どうすればmyapp.exeと連携できるのでしょうか?

libstdc++が同じ動的にロードされた標準ライブラリを使用することができますmyapp.exelibplug.so両方以来、動的にリンクされている場合、これは簡単ですが、それは最高の静的にリンクされた標準ライブラリでこれを行う方法を私にははっきりしません。

私が検討しているアプローチはlibplug.soもフラグ-static-libstdc++を使用して、標準ライブラリのそのバージョンが使用されていることを確認するために、それはあるだろう意味でしょうversion script

{ 
    global: plugf; 
    local: *; 
}; 

を使用することですメモリにロードされたlibstdc++の2つのコピー。 ORDの違反があるので、このアプローチはC++の標準に恵まれないことは知っていますが、どんな形でもlibstdc++がサポートしていますか? manualセクションのMultiple ABI testingセクションは、同様のシナリオを参照しています。

+1

悲しいことに、libplug.soとマッチするように動的/静的リンクされたlibstdC++を配布する必要があります。実行時に2つのコピーがロードされます。そして、あなたのプラグインがあるバージョンのlibstdC++でポインタを返し、別のバージョンでそれを解放すれば、あなたは困ってしまうかもしれません。 – Mikhail

+0

私はそれが本当だとは思わない。割り当ては標準のcライブラリによって処理され、 '-static-libstdC++'は 'libc'を静的にリンクさせないので、両方とも同じ' libc.so'を使用します。 – rnickb

+0

オブジェクトはlibstdC++の '__gnu_cxx :: new_allocator'で割り当てられていると思います。おそらく、両方とも同じ' libc.so'を指していると思います。個人的な経験から私はMSVCのRTを使って上記の問題を抱えていました。 – Mikhail

答えて

1

はい、このソリューションは動作しますが、

  • それはあなたがプラグイン/アプリ間でSTLオブジェクトを渡すようにしようとした場合、それが原因ABI changes in recent libstdc++
に破損することにより、コードの重複
  • に一定のオーバーヘッドを紹介

    別のC++ランタイムでstd::allocatorによって割り当てられたオブジェクトを削除することは、libstdC++ docsでこれについて明示的に声明を見つけることはできませんでしたが、Linux上で動作するはずです。 Mikhailがコメントで指摘したように、Windows上では失敗します。

  • +0

    ABIの変更は、libstdC++のC++ 98とC++ 11のバージョン間でのみです。 – rnickb

    +1

    @rnickbいいえ、 '-std'フラグに関係なく、新しいGCC5以降のlibstdC++で新しいABIを取得します([このページ](https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html参照)。 ) 詳細については)。 '-std = C++ 98'と' -std = C++ 11'でコンパイルされたコード中の 'std :: string'はバイナリ互換である方がよいからです。 – yugr

    関連する問題