1

考虑以下代码，用于在 linux 上使用 g++-4.7 构建的动态加载库，-fPIC并与-rdynamic选项链接： 

struct Wrapper
{
    libraryUnregisterCbMap_t instance;
    Wrapper() : instance() { HDebugLog("Wrapper CTOR!");}
    ~Wrapper() { HDebugLog("Wrapper DESTRUCTOR!"); }
};
inline libraryUnregisterCbMap_t& getLibraryUnregisterMap()
{
    static Wrapper unregisterLibraryMap;
    HDebugLog("getLibraryUnregisterMap: we have " <<unregisterLibraryMap.instance.size() << " elements. the address of the map is " << &unregisterLibraryMap.instance);
    return unregisterLibraryMap.instance;
}

void registerLibrary(callbackContainer_t* p)
{
  auto& map = getLibraryUnregisterMap();
}

void unregisterLibrary()
{
  auto& map = getLibraryUnregisterMap();
}

void __attribute__ ((constructor)) library_init()
{
  static callbackContainer_t cbContainer;
  HDebugLog("Library constructor: address of static cbContainer is: " << &cbContainer );
  registerLibrary( &cbContainer);
} 
void __attribute__ ((destructor)) library_fini()
{ unregisterLibrary(); }

对我来说有趣/烦人的部分是 library_fini() 在我调用之后没有被调用lt_dlclose，所以它似乎对最终确定毫无用处，因为当我在运行期间加载这个模块时，Wrapper实例的析构函数发生在调用之前library_fini。不用说，这种默认行为没有任何意义。

我该如何改变这种无意义的行为？我需要在我的库完成例程中完成我的静态数据。为什么lt_dlclose不调用library_fini()？

4

1 回答 1

0

让我首先承认我在这里超出了我的深度。也就是说，谷歌搜索出现了一个线程，至少据我所知，它似乎解决了与你类似的问题：

http://lists.apple.com/archives/xcode-users/2005/Aug/msg00133.html

你碰巧在做你在 OSX 上做的任何事情吗？线程中有一些东西（可能是第二个后续）关于 OSX 的行为不同，即不调用析构函数，而只是将内存设置为空闲。

抱歉，如果链接没有用。只是想我会试一试，因为此时没有其他人回答。

编辑：

再次，超出我的深度 - 但我发现了另外两个可能相关的链接：

  1. http://phoxis.org/2011/04/27/c-language-constructors-and-destructors-with-gcc/

    • 在评论中，人们提到在使用析构函数时遇到问题exit，并且必须使用该atexit函数来克服这些问题

  2. http://clang-developers.42468.n3.nabble.com/Priority-settings-for-static-variables-and-attribute-destructor-td4030466.html

    • 在调用属性((destructor)) 函数之前破坏的全局资源。建议的解决方案是使用析构函数的优先级。
于 2013-04-02T05:34:38.287 回答