当我静态链接它时，为什么要寻找dylib?该如何解决?

Apple的链接器使用dylib或共享对象(如果可用)，而与-rpath和-Bstatic之类的链接器标志无关.他们甚至在不允许dylib的iOS上执行此操作！

一旦知道，它就是一个众所周知的问题:)例如，参见在Mac OS上安装Crypto ++ 5.6.2 X . Crypto ++在Apple的工具中也有同样的问题.

解决方法是使用-L和-l选项停止，并直接链接目标文件或归档.存档只是目标文件的集合，因此您可以互换使用它们.

要为链接器指定目标文件或归档，请参见链接到目标文件.在Xcode下，将完全指定的存档名称(如/usr/local/openssl-ios/lib/libcrypto.a)添加到 Other Linker Flags ( Xcode中进行记录构建设置参考，但显然在我的Xcode副本下.请参阅如何在Stack Overflow上链接iOS的静态库.

我似乎回想起过去在此方面遇到的问题.它是应该在理论上起作用但在实践中不起作用的事物之一.

---

第三个选择是从Xcode下使用的所有路径中删除dylib或共享库，以便Xcode在使用-lcrypto时不会意外找到它.

---

第四个选项是使用允许动态链接，但使用代码签名或 Gatekeeper服务 ...

要在MAC Developer程序下对库的副本进行代码签名，只需:

 codesign -fs "Johnny Developer" /usr/local/ssl/lib/libcrypto.so
 

I am trying to link libssl.a and libcrypto.a static libraries in XCode command line project [under Link Binary With Libraries]. I have included Openssl header files in search path.

Compilation succeeds but execution fails with dyld: Library not loaded: /usr/local/ssl/lib/libcrypto.1.0.0.dylib.

Why does it look for dylib when I am linking it statically? How can this be fixed?

Any help would be appreciable.

Why does it look for dylib when I am linking it statically? How can this be fixed?

Apple's linker uses the dylib or share object if its available, regardless of of your linker flags like -rpath and -Bstatic. They even do it on iOS, where dylib's are not allowed!

Its kind of a well known problem once you know about it :) See, for example, Installing Crypto++ 5.6.2 on Mac OS X. Crypto++ has the same problems with Apple's tools.

The fix is to stop using -L and -l options, and to link the object file or archive directly. An archive is just a collection of object files, so you can use them interchangeably.

To specify the object files or archives for the linker, see Linking to an object file. Under Xcode, you add the fully specified archive name (like /usr/local/openssl-ios/lib/libcrypto.a) to Other Linker Flags (the OTHER_LDFLAGS Xcode option).

When adding the full archive to OTHER_LDFLAGS, I believe you just add it verbatim without any switches, like -l or -L. You may need -Wl (-Wl,/usr/local/openssl-ios/lib/libcrypto.a), but you don't use -l (-l/usr/local/openssl-ios/lib/libcrypto.a).

You use -Wl when the option is passed through the compiler driver to the linker. If the linker is invoked directly, then you don't need -Wl and should not use it.

---

A second option is to set GCC_LINK_WITH_DYNAMIC_LIBRARIES to YES. Apple does not appear to document it in Xcode Build Setting Reference, but its clearly under my copy of Xcode. See How to link a static library for iOS on Stack Overflow.

I seem to recall having problems with this in the past. Its one of those things that should work in theory, but does not work in practice.

---

A third option is to remove the dylib or shared object from all paths used under Xcode so Xcode does not accidentally find it when using -lcrypto.

---

A fourth option is use allow dynamic linking, but execute the program with DYLD_LIBRARY_PATH. Its OS X's equivalent to LD_LIBRARY_PATH, and ensures your copy of OpenSSL is loaded (like 1.0.2), and not the system's version of OpenSSL (0.9.8).

But I don't like this option because it requires users of your software to do something.

---

Another possibility due to the message dyld: Library not loaded: /usr/local/ssl/lib/libcrypto.1.0.0.dylib is to code sign your copy of the library. Its a little odd its found but not loaded, so I'm going to toss this out there in case its OS X's Code Signing or Gatekeeper Service...

To code sign your copy of the library under the MAC Developer program, just:

codesign -fs "Johnny Developer" /usr/local/ssl/lib/libcrypto.so