C++ 是否可以通过编程方式使OS X中的dlopen（）返回NULL？

我们称之为x.dylib。我只希望有时加载x.dylib

在dylib的初始化过程中，是否有任何方法可以使试图加载x.dylib的dlopen（）调用无法加载x.dylib并返回NULL

重命名x.dylib不是一个选项

我看了一遍，但对代码不熟悉

我想也许这可以做到：

__attribute__((constructor))                                                   
void initializer(void) {                                                       
    fprintf(stderr, "initializer\n");                                          
    throw;                                                                     
}

但是当我用那个初始值设定项在动态库上调用dlopen（）时，我只得到了“

初始值设定项”
在没有活动异常的情况下终止调用Bort陷阱：6

“

所以我被难住了；任何帮助都会很好

编辑： 当使用gdb查看时，堆栈跟踪如下所示：

Program received signal SIGABRT, Aborted.
0x00007fff9128a82a in __kill ()
(gdb) bt
#0  0x00007fff9128a82a in __kill ()
#1  0x00007fff93539a9c in abort ()
#2  0x00007fff987f07bc in abort_message ()
#3  0x00007fff987edfcf in default_terminate ()
#4  0x00007fff987ee001 in safe_handler_caller ()
#5  0x00007fff987ee05c in std::terminate ()
#6  0x00007fff987ef152 in __cxa_throw ()
#7  0x0000000100003eb5 in initializer ()
#8  0x00007fff5fc0fda6 in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE ()
#9  0x00007fff5fc0faf2 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()
#10 0x00007fff5fc0d2e4 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE ()
#11 0x00007fff5fc0d27d in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE ()
#12 0x00007fff5fc0e0b7 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE ()
#13 0x00007fff5fc034dd in __dyld__ZN4dyld24initializeMainExecutableEv ()
#14 0x00007fff5fc0760b in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
#15 0x00007fff5fc01059 in __dyld__dyld_start ()

来自：

---

我很惊讶，我在堆栈跟踪中没有看到dlopen（）

试着抛出一个

常量字符*

，也许吧？乍一看，dyld_open代码只捕获类型为

const char*

的抛出内容。当我

抛出s时，会显示相同的消息

，其中

s

是常量字符*.Hmm。如果您在gdb中使用“catch-throw”，您可以在抛出异常时捕获异常，这可能会提供更多信息的回溯。这就像试图编写一个可执行文件，导致系统在尝试执行时报告找不到文件。想要这样做是没有意义的。这里没有调用

dlopen（）

。堆栈跟踪显示dyld在启动时正在加载程序和它链接的所有库（以及它们链接的所有库，等等）。这与调用

dlopen（）

完全不同

dlopen（）

可能会正常失败。无法加载程序所依赖的库（直接或间接）是一个硬故障。如果您成功地实现了它，这将意味着整个程序的加载将失败，就像您删除或重命名x.dylib使其完全找不到一样。